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FORK WORD 


Sneak  Circuit  Analysis  (SCA)  is  a  technique  for  evaluating  hardware 
systems  and  software  programs.  The  purpose  of  this  analysis  technique 
is  to  identify  latent  circuits  and  conditions  that  could  inhibit  desired 
functions  or  cause  undesired  Functions  to  occur.  By  definition,  sneak 
conditions  are  not  caused  by  failures,  but  rather  they  represent  conditions 
inadvertently  designed  into  the  hardware  system  or  software  program. 

The  SCA  technique,  hv  that  name,  is  a  relatively  modern  innovation,  but 
manv  facets  of  the  analysis  are  similar  to  long  standing  techniques.  The 
SCA  is  unique  in  that  it  represents  a  very  formalized,  structured,  and 
orderly  process  providing  a  high  degree  of  confidence  that  unintended 
conditions  have  not  been  introduced  into  the  hardware  or  software.  As  such, 
it  complements,  but  does  not  replace  or  supersede,  other  common  design 
an. •lysis  techniques  such  as  the  failure  modes  and  effects  analysis  (FMEA) , 
safety  hazard  analysis,  component  stress  analysis,  etc. 

Sneak  conditions  may  result  from  several  factors,  but  the  primary  causes 
are  lack  of  total  system  overview,  integration  of  changes,  and  just  plain 
human  error  or  oversight.  As  hardware  systems  and  software  programs  become 
increasingly  more  sophisticated  and  complex,  inevitably  involving  more 
interfaces  between  hardware  elements,  software  elements,  and  human  elements, 
the  need  for  the  SCA  (or  equivalent  techniques)  becomes  more  pronounced. 

Management  and  engineering  personnel  involved  in  the  design  and  develop¬ 
ment  of  systems  and  equipment  should  be  sufficiently  familiar  with  the  SCA 
technique  to  permit  them  to  make  appropriate  decisions  regarding  its  applica¬ 
bility  to  their  programs,  as  well  as  to  effectively  manage  the  effort  for  the 
greatest  return  on  investment. 

The  dec i si  on  to  require  the  SCA  (or  not  to  require  it)  on  a  given  program 
involves  rather  complex  trade-offs.  Among  these  are  cost  versus  potential 
benefits,  system  criticality,  system  complexity,  and  comprehensiveness  of 
other  planned  analyses  and  test  programs.  Accordingly,  the  intent  of  this 
document  is  to  explain  the  SCA  process  in  terms  of  what  it  is  designed  to 
accomplish,  with  consideration  given  to  potential  benefits  as  well  as  penalties. 
Further,  the  document  provides  guidelines  for  the  ordering  and  management  of 
the  SCA  as  well  as  methods  for  evaluation  of  prospective  SCA  contractors  and 
the  results  of  their  analvses. 

Bequests  for  copies  of  this  manual  from  U.S.  Government  activities  should 
he  forwarded  to: 

Commanding  Officer 

Naval  Publications  and  Forms  Center 

1801  Tabor  Avenue 

Philadelphia,  Pennsylvania  19120 

Requests  from  industry  should  he  forwarded  to  the  same  address  via  the  local 
I'.S.  Government  Representative  (  e.g  .  ,  DCASA)  or  may  be  purchased  directly  from 
the  same  address,  ATTN:  Code  KOIG. 

Prepared  bv :  Naval  Sea  Systems  Command 

SEA  bill 

Washington,  P.C.  20162 
September  1980 
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1.0  SCOPE 


1.1  General .  This  guide  presents  a  description  of  the  Sneak  Circuit 
Analysis  (SCA)  with  primary  emphasis  on  its  purpose  and  potential  ben¬ 
efits,  as  well  as  cost  factors  and  trade-offs.  It  is  not  the  intent  of 
the  guide  to  define  the  exact  methods  or  techniques  for  the  performance 
of  the  analysis.  The  following  topics  relating  to  the  SCA  are  addressed 

a.  What  is  a  Sneak  Circuit  Analysis? 

b.  Why  would  the  SCA  be  performed? 

c.  Who  performs/participates  in  the  SCA? 

d.  When  should  the  SCA  be  performed? 

e.  How  is  the  SCA  ordered  and  managed? 

f.  What  are  the  associated  cost  factors?. 


1.2  Purpose.  The  purpose  of  this  guide  is  to  familiarize  management 
and  engineering  personnel  responsible  for  the  design  and  development  of 
systems  and  equipment  with  the  SCA  concept,  and  thus  enable  them  to  make 
appropriate  decisions  regarding  its  applicability  to  a  given  program. 
Guidelines  are  provided  for  the  management  and  implementation  of  the 
SCA. 

1.3  Appl ication.  The  SCA  concept  has  potential  applications  in  any 
design  or  development  program  for  systems,  equipment,  or  software  and 
its  merits  should  be  evaluated  as  part  of  the  development  planning 
effort.  In  the  past,  the  SCA  was  generally  considered  applicable  only  to 
electrical  and  electronic  circuits,  but  the  concept  has  evolved  to  where 
it  can  be  used  to  evaluate  other  systems,  including  mechanical,  pneu¬ 
matic,  hydraulic,  power  generation,  etc.  The  complexity  and  criticality 
of  such  systems  or  equipments,  the  extent  of  other  analyses  and  test 
programs,  and  the  associated  cost  factors  are  the  primary  determinants 
in  the  decision  to  require  (or  not  to  require)  the  SCA. 

1.4  Organization.  This  guide  has  been  organized  in  a  manner  intended 
to  be  most  useful  to  those  personnel  who  participate  in  the  decision 
making  process  as  to  whether  or  not  the  technique  is  appropriate,  and 
then  to  those  who  are  to  implement  the  process.  Accordingly,  the  pro¬ 
gram  or  project  manager  should  not  find  it  necessary  to  read  beyond  the 
FOREWORD,  SCOPE,  and  Section  4.0  to  make  decisions  such  as  (1)  non- 
applicable,  (2)  further  study  by  appropriate  engineering  disciplines  is 
warranted  or  (3)  definitely  applicable,  extent  to  be  established.  If 
the  technique  is  determined  to  be  potentially  applicable  in  a  given 
situation,  the  program  or  project  manager  should  per  use  the  discussions 
of  cost  and  schedule,  presented  in  Section  7.0  and  9.0.  The  decision  to 
require  or  not  require  the  SCA  does  not  differ  substantially  from  other 
program  decisions,  in  that  potential  benefits,  relationships  to  other 
efforts,  costs,  availability  of  resources,  schedule  impact,  and  penal 
ties  or  risks  of  not  performing  this  effort,  must  be  considered. 


2.0  APPLICABLE  DOCUMENTS 


2.1  Specifications  and  standards.  The  following  documents,  of  the 
issue  in  effect  on  the  date  of  invitations  for  bid  or  requests  for 
proposals,  form  a  part  of  this  guide  to  the  e,  tent  specified  herein: 

Specifications,  Military: 

MIL-M-24100  -  Manual,  Technical,  Functionally  Oriented  Main 

tenance  Manuals  (FOMM),  for  Equipments  and  Systems 


Standards,  Military : 


MIL-STD-280 


Definitions  of  Item  Levels,  Item  Exchangeability, 
Models,  and  Related  Terms 


M I L- STD- 72 1  -  Definitions  of  Effectiveness  Terms  for  Reliability, 

Maintainability,  Human  Factors,  and  Safety 

MIL-STD-785  -  Reliability  Program  for  System  and  Equipment, 
Development  and  Production 


MIL-STD-882 


System  Safety  Program  Requirements 


M I L- STD- 1472 


Human  Engineering  Design  Criteria  for  Military 
Systems,  Equipments,  and  Facilities 


MIL-STD-1679 


Weapon  System  Software  Development 


(Copies  of  specifications,  standards,  and  other  publications  required  by 
contractors  in  connection  with  specific  procurement  functions  should  be 
obtained  from  the  procuring  activity  or  as  directed  by  the  contracting 
officer.) 
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3.0  DEFINITIONS 


3.1  General .  Definitions  of  terms  used  in  this  guide  are  in  ac¬ 
cordance  with  MIL-STD-280  and  MIL-STD- 721 .  Specialized  terms  unique  to 
the  SCA  technique  are  defined  in  the  following  subparagraphs  in  the 
context  used  in  this  publication. 

3.1.1  Cl ue.  A  known  relationship  between  a  historically  observed 
sneak  circuit  condition  and  the  underlying  causes  which  created  it. 

Clues  are  used  to  evaluate  other  systems  for  possible  sneak  circuit 
condi tions. 

3.1.2  Contractor.  An  activity  (agency)  used  to  perform  some  service 
to  a  government  agency.  As  used  herein,  contractor  may  refer  to  another 
government  activity. 

3.1.3  G1 itch.  An  anomolous  circuit  response  which  occurs  without 
apparent  reason,  generally  due  to  signal  overlap  or  timing  problems. 

3.1.4  Hi ghl ight.  The  process  of  isolating  a  particular  design 
feature  which  is  likely  to  generate  a  system  malfunction,  so  that  it  can 
be  subjected  to  intensive  analysis. 

3.1.5  Manual  SCA  procedures.  SCA  procedures  that  are  performed 
without  computer  assistance. 

3.1.6  Network.  A  group  of  interconnnected  elements  intended  to 
perform  some  system  function.  Elements  may  be  electrical  components, 
electromechanical  components,  computer  program  instructions,  operator 
actions,  procedures,  mechanical  or  pneumatic  functions,  or  any  other 
portion  of  a  system  that  can  be  considered  as  an  independent  entity. 
Although  the  networks  most  frequently  considered  in  SCA  consist  of 
electrical  and  electromechanical  components,  the  definition  is  not 
restricted  to  networks  of  this  type. 

3.1.7  Path  search.  A  process  of  searching  out  all  possible  paths 
through  a  network. 

3.1.8  Software.  A  computer  program  which  may  be  either  an  inde¬ 
pendent  (stand-alone)  program  or  an  embedded  (within  other  system 
hardware)  program. 

3.1.9  Tailoring.  The  process  of  adapting  a  specification  to  fit  the 
constraints  of  a  particular  program. 

3.1.10  Topological  methods.  Sneak  circuit  analysis  procedures  which 
are  based  primarily  on  the  relationship  between  known  sneak  conditions 
and  the  network  patterns  they  display  in  a  schematic  diagram. 
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3.1.11  Trade-off.  The  process  of  comparing  the  relative  advantages 
and  disadvantages  of  different  courses  of  action. 

3.1.12  V&V.  Verification  and  Validation,  generally  referring  to 
those  activities  in  a  software  development  program  that  serve  to  assure 
the  adequacy  and  the  accuracy  of  the  software. 


4.0  GENERAL  DESCRIPTION 


4.1  Sneak  circuit.  A  sneak  circuit  is  an  unexpected  path  or  logic 
flow  within  a  system  which,  under  certain  conditions,  can  initiate  an 
undesired  function  or  inhibit  a  desired  function.  The  path  may  consist 
of  hardware,  software,  operator  actions,  or  combinations  of  these 
elements.  Sneak  circuits  are  not  the  result  of  hardware  failure  but  are 
latent  conditions,  inadvertently  designed  into  the  system  or  coded  into 
the  software  program,  which  can  cause  it  to  malfunction  under  certain 
conditions.  Categories  of  sneak  circuits  are: 

a-  Sneak  paths  which  cause  current,  energy,  or  logical  sequence 
to  flow  along  an  unexpected  path  or  in  an  unintended  direction 

b.  Sneak  timing  in  which  events  occur  in  an  unexpected  or  con¬ 
flicting  sequence. 

c.  Sneak  indications  which  cause  an  ambiguous  or  false  display  of 
system  operating  conditions  and  thus  may  result  in  an  un¬ 
desired  action  taken  by  an  operator. 

d.  Sneak  labels  which  incorrectly  or  imprecisely  label  system 
functions,  e.g.,  system  inputs,  controls,  displays,  buses, 
etc.,  and  thus  may  mislead  an  operator  into  applying  an 
incorrect  stimulus  to  the  system. 

Figure  1  depicts  a  simple  sneak  circuit  example.  With  the 
ignition  off,  the  radio  turned  to  the  on  position,  the  brake  pedal 
depressed  and  the  hazard  switch  engaged  the  radio  will  power  on 
with  the  flash  of  the  brake  lights. 


Figure  1.  Automotive  Sneak  Circuit. 
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4.2  Sneak  circuit  analysis  (SCA).  Sneak  circuit  analysis  is  the  term 
that  has  been  applied  to  a  group  of  analytical  techniques,  which  are 
intended  to  methodically  identify  sneak  circuits  in  systems.  SCA  tech¬ 
niques  may  be  either  manual  or  computer-assisted,  depending  on  system 
complexity.  Current  SCA  techniques  which  have  proven  useful  in  iden¬ 
tifying  sneak  circuits  in  systems  include: 

a.  Sneak  path  analysis  -  A  methodical  investigation  of  all  possible 
electrical  paths  in  a  hardware  system.  Sneak  path  analysis  is 

a  technique  used  for  detecting  sneak  circuits  in  hardware 
systems,  primarily  power  distribution,  control,  switching 
networks,  and  analog  circuits.  The  technique  is  based  on 
known  topological  similarities  of  sneak  circuits  in  these 
types  of  hardware  systems. 

b.  Digital  sneak  circuit  analysis  -  An  analysis  of  digital  hard¬ 
ware  networks  for  sneak  conditions,  operating  modes,  timing 
races,  logical  errors,  and  inconsistencies.  Depending  on 
system  complexity,  digital  SCA  may  involve  the  use  of  sneak 
path  analysis  techniques,  manual  or  graphical  analysis, 
computerized  logic  simulators  or  computer-aided  design  (CAD) 
circuit  analysis. 

c.  Software  sneak  path  analysis  -  An  adaptation  of  sneak  path 
analysis  to  computer  program  logical  flows.  The  technique  is 
used  to  analyze  software  logical  flows  by  comparing  their 
topologies  to  those  with  known  sneak  path  conditions  in  them. 

d.  Other  sneak  circuit  analysis  techniques  -  Because  the  tech¬ 
nology  of  hardware  and  software  systems  is  evolving  at  a  rapid 
rate,  new  SCA  techniques  will  undoubtedly  evolve  as  well.  The 
technique  will  also  find  use  in  analysis  of  other  than  elec¬ 
trical,  or  electronic  systems  (such  as  mechanical,  hydraulic, 
pneumatic,  etc.),  where  analogous  situations  of  energy  flow, 
logic  timing,  etc.  are  encountered. 

4.3  Sources  of  sneak  conditions.  Sneak  conditions  result  from  the 
following  three  primary  sources:  system  complexity,  system  changes,  and 
user  operations.  Hardware  or  software  system  complexity  results  in  numerous 
subsystem  interfaces  that  may  obscure  the  intended  functions  or  produce 
unintended  functions.  The  effects  of  even  minor  wiring  or  software 
changes  to  specific  subsystems  may  result  in  undesired  system  opera¬ 
tions.  A  system  that  is  relatively  sneak  free  can  be  made  to  circumvent 
desired  functions  or  generate  undesired  functions  as  a  consequence  of 
improper  user  operations  or  procedures.  As  systems  become  more  complex, 
the  number  of  human  interfaces  multiply  because  of  the  involvement  of 
more  design  groups,  subcontractors ,  and  suppliers,  and  the  probability 

of  overlooking  potentially  undesirable  conditions  is  increased 
proportionately. 
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4.4  Historical  development.  Systems  analysis  techniques,  in  one  form 
or  another,  have  been  employed  throughout  the  evolution  of  the  various 
technologies.  As  systems  become  more  and  more  complex,  and  as  greater 
emphasis  is  placed  on  safety  and  reliability,  the  need  for  more  sophis¬ 
ticated  techniques  evolves.  The  development  of  the  SCA,  as  a  unique 
analytical  technique  under  that  name,  came  about  when  it  was  recognized 
that  conventional  analytical  methods  did  not  identify  certain  subtle 
anomalies  in  systems  design.  The  first  investigations  using  SCA  tech¬ 
niques  were  initiated  in  the  1960s  by  NASA  to  identify  sneak  conditions 
in  missile  launch  command  and  control  electrical  subsystems.  An  SCA 
technique  was  developed  that  would  reveal  sneak  circuits  in  these  type 
systems,  and  it  was  successfully  used  on  the  Apollo  space  program.  SCA 
was  later  expanded  to  encompass  analog  systems  and  digital  logic,  and 
subsequently  to  include  software  and  software/hardware  integration.  The 
SCA  technique  can  also  be  applied  to  hydraulic,  pneumatic,  and  other 
analogous  systems  and  has  been  used  in  the  analysis  of  detailed  system 
operating  procedures. 

4.5  Relation  to  other  analyses.  A  major  consideration  in  other 
analyses  is  the  potentiaT  effect  of  component  and/or  subsystem  failures, 
and  methods  for  preventing  or  mitigating  such  effects.  On  the  other 
hand,  the  SCA  considers  the  potential  that  an  undesired  function  may 
occur,  or  that  a  desired  function  may  be  inhibited,  given  that  the 
system  is  performing  as  designed.  Thus,  the  SCA  looks  at  the  system 
from  a  different  perspective,  and  complements  these  other  techniques, 
but  does  not  replace  them.  To  an  extent,  the  SCA  will  identify  many  of 
the  same  potential  problems  as  the  other  techniques  and  might  therefore 
be  considered  somewhat  redundant,  or  it  might  be  considered  a  desirable 
"double-check"  for  these  aspects,  depending  on  how  one  views  it. 

4.6  Relation  to  test  programs.  Most  test  programs  are  designed  to 
determine  if  desired  functions  occur  under  given  conditions.  It  is 
seldom  feasible  to  test  all  combinations  of  conditions  that  might  result 
in  undesirable  or  unexpected  functions.  Tests  frequently  can  be  per¬ 
formed  on  only  a  limited  number  of  items,  which  typically  will  not 
represent  the  range  of  variables  that  may  be  inherently  present  in  the 
total  population  of  a  given  item.  Tests  are  expensive,  and  in  many 
instances,  destructive  in  nature.  Thus,  test  programs  are  not  a  viable 
substitute  for  analyses  of  any  type.  However,  the  results  of  analyses 
(such  as  SCA)  may  identify  potential  problems,  allowing  the  test  pro¬ 
gram  to  be  structured  such  that  if  these  problems  are  present,  they  will 
be  detected. 

4.7  SCA  techniques.  SCA  has  been  successfully  applied  to  a  variety 
of  system  types.  Somewhat  different  SCA  techniques  are  appropriate  to 
each  of  the  different  types  of  systems,  e.g.,  computerized  path  search 
methods  are  particularly  useful  in  analyzing  relay  switching  systems 
and  power  distribution  circuits,  but  are  not  completely  sufficient  in 
analyzing  digital  circuits.  As  new  hardware  technologies  have  evolved. 
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SCA  techniques  have  been  adapted  and  improved  in  order  to 
unwanted  or  unexpected  system  operating  modes  before  they 
into  the  deliverable  hardware.  Different  contractors  may 
problem  in  different  but  more  or  less  equivalent  ways.  At 
types  of  SCA  are  in  current  use;  (1)  sneak  path  analysis, 
SCA,  and  (3)  software  sneak  path  analysis.  Several  other 
also  been  postulated. 


identi fy 
are  propagated 
approach  the 
least  three 
(2)  digital 
methods  have 


4.7.1  Sneak  path  analysis.  This  method  of  SCA  attempts  to  discover 
sneak  circuit  conditions  by  means  of  methodical  analysis  of  all  possible 
electrical  paths  through  a  network.  Because  of  the  large  volume  of  data 
involved,  sneak  path  analysis  normally  mandates  computer  data  proc¬ 
essing.  It  has  been  found  that  sneak  circuit  conditions  generally  have 
certain  common  characteristics  which  are  directly  related  to  topological 
patterns  within  the  network.  Sneak  path  analysis  uses  these  common 
characteristics  as  "clues"  to  look  for  sneak  circuits  in  the  system 
being  analyzed. 


4.7.2  Digital  SCA.  This  method  of  SCA  is  intended  to  discover  sneak 
circuit  conditions  in  digital  systems.  Digital  SCA  may  involve  some 
features  of  sneak  path  analysis,  but  it  may  also  involve  additional 
computer  assisted  techniques  such  as  computerized  logic  simulation, 
timing  analysis,  etc.,  to  handle  the  multiplicity  of  system  states 
encountered  in  modern  digital  designs.  In  general,  digital  SCA  will 
identify  the  following  types  of  anomalies: 

a.  Logic  inconsistencies  and  errors, 

b.  Sneak  timing,  that  is,  a  convergence  of  signals  which  causes 
an  erroneous  output  due  to  differing  time  delays  along  dif¬ 
ferent  signal  paths  through  a  digital  network, 

c.  Excessive  signal  loading  or  fan-out,  and 

d.  Power  supply  cross-ties,  grounding,  or  other  misconnections  of 
signal  pins. 

4.7.3  Software  sneak  path  analysis.  Software  sneak  path  analysis  was 
adapted  from  hardware  sneak  path  analysis.  It  was  found  that  computer 
program  flow  diagrams  which  contained  known  sneak  paths  were  most  often 
associated  with  certain  common  flow  diagram  topologies  and  had  other 
common  characteristics.  These  common  characteristics  served  as  a  basis 
for  establishing  "clues"  which  could  be  used  to  analyze  new  computer 
program  flow  diagrams.  Computerized  path  search  programs  developed  to 
do  SCA  on  hardware  were  adapted  or  rewritten  to  accept  software  logical 
flows,  and  new  clues  were  developed  to  analyze  them.  Software  SCA  can  be 
done  either  manually  or  with  computer  assistance,  depending  primarily  on 
the  size  and  complexity  of  the  software.  It  may  be  combined  with  the 
hardware  SCA  and  is  most  often  used  on  embedded  software  in  a  complete 
minicomputer  or  microcomputer-controlled  hardware  system.  It  has  been 
used  on  both  assembly  language  and  higher  order  language  programs. 
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4.7.4  Other  SCA  techniques.  Variations  of  the  SCA  have  been  developed 
to  analyze  particular  types  or  combinations  of  systems,  such  as  hardware/ 
software  interfaces.  The  application  of  any  new  SCA  procedure  to  a 
particular  system  or  situation  must  be  judged  on  its  demonstrated  effec¬ 
tiveness  in  detecting  sneak  circuits  in  similar  cases  or  on  its  antic¬ 
ipated  benefit  in  the  specific  situation  being  considered.  This  guide 
cannot  explicitly  predefine  a  course  of  action  for  handling  new  SCA 
types  which  may  emerge,  but  the  general  ground  rules  for  evaluating 
applicability  will  apply. 

4.8  , 'Manual  vs.  computer-aided  SCA.  All  of  the  defined  types  of  SCA, 
i.e.,  sneak  path  analysis,  digital  SCA,  and  software  sneak  path  analysis 
may  be  performed  manually  under  some  limited  conditions.  Computer- 
assisted  SCA  data  processing  is  also  possible  with  each  of  these  types 
and  is  absolutely  essential  for  more  complex  systems.  The  availability 
and  thoroughness  of  computer  aids  would  strongly  influence  the  selection 
of  a  contractor  to  perform  SCA  on  a  complex  system. 

4.8.1  Typical  computer  aids.  Computer  aids  which  may  be  used  to 
assist  in  performing  SCA  tasks  on  large  systems  include: 

a.  Configuration  management,  programs  to  handle  large  volumes  of 
system  configuration  data. 

b.  Automated  path  search,  network  plotting,  and  "clue"  evaluation 
programs  used  in  sneak  path  analysis. 

c.  Digital  logic  analyzer  programs  used  on  complex  digital  systems. 

d.  Circuit  analysis  and  design  programs  used  to  analyze  sub¬ 
circuits  and  functions. 

e.  Code  analyzers,  and  in  some  cases,  compilers  for  software 
programs. 

f.  Report  generation  programs. 

4.8.2  Integration  with  other  techniques.  Some  contractors  may  integrate 
their  computer-aided  SCA  programs  with  CAD  or  circuit  analysis  progrars 
which  perform  other  functions  that  are  not  specifically  SCA  procedures , 
such  as,  stress  analysis,  worst  case  design  analysis,  failure  modes 
analysis,  or  even  with  automatic  wire-wrap  software.  These  other 
features  may  influence  the  selection  of  a  contractor  to  perform  SCA 
because  of  cost  efficiencies  to  be  realized. 


4.8.3  Manual  techniques.  One  technique  that  has  been  effective  in 
identification  of  some  of  the  same  types  of  anomalies  that  are  disclosed 
by  the  SCA  is  the  development  of  the  functional  logic  diagrams  and  the 
associated  baseline  data  required  in  the  preparation  of  Functionally 
Oriented  Maintenance  Manuals  in  accordance  with  MIL-M-24100.  For 
systems  requiring  such  manuals,  the  baseline  data  would^serve  as  an 
input  to  the  SCA,  and  could  be  considered  adequate  in  lieu  of  the  SCA, 
in  some  situations.  Other  manual  techniques,  such  as  the  construction 
of  graphic  logic  diagrams,  have  been  used  successfully.  Generally, 
however,  manual  techniques  are  not  viable  on  other  than  rather  simple 
systems. 
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5.0  PURPOSE,  BENEFITS,  TRADE-OFFS 


5.1  Benefits  of  SCA.  Sneak  Circuit  Analysis  offers  three  principal 
benefits  in  the  analysis  of  systems  which  distinguish  it  in  some  re¬ 
spects  from  other  analytical  techniques. 

a.  Sneak  conditions  are  distinguished  from  other  types  of  mal¬ 
functions  primarily  by  their  resistance  to  conventional  forms 
of  analysis.  Thus,  SCA  can  identify  such  problems  as  un¬ 
intended  current  paths,  false  indications,  misleading  labels, 
sneak  timing  or  signal  race  conditions,  "glitch"  conditions, 
and  many  "intermittent"  problems  which  occur  at  only  one 
portion  of  an  operational  cycle  or  are  the  result  of  proce¬ 
dural  causes  rather  than  faulty  components.  SCA  is  a  "high¬ 
lighting"  technique  which  isolates  particular  areas  of  the 
system  that  are  most  likely  to  generate  sneak  conditions  and 
applies  intensive  analysis  of  those  areas  to  look  for  possible 
system  malfunctions.  Consequently,  SCA  is  much  more  efficient 
in  finding  design  flaws  which  would  be  classified  as  "sneak" 
conditions  than  other  more  conventional  analyses. 

b.  SCA  inherently  results  in  a  reasonably  thorough  design  review 
by  qualified  analysts  with  experience  and  training  in  the  type 
of  system  being  analyzed.  The  analysts  generally  will  possess 

a  list  of  "clues"  which  are  applied  to  isolate  sneak  conditions. 
Most  of  these  clue  lists  also  contain  a  variety  of  other 
common  design  oversights  to  consider  when  performing  the  SCA. 
While  the  SCA  cannot  be  considered  comprehensive  in  these 
other  areas,  it  provides  a  "second  check"  of  other  more 
specific  analyses,  such  as  stress  analysis,  FMECA,  etc.  It  has 
been  found  that  the  SCA  frequently  identifies  problems  in 
related  areas  such  as: 

(1)  Overstressed  parts, 

(2)  Single  failure  points, 

(3)  Unnecessary  or  unused  circuitry  or  components, 

(4)  Lack  of  relay  transient  protection, 

(5)  Excessive  fan-out  on  microcircuits, 

(6)  Component  misapplication, 

(7)  Drawing  errors,  etc. 

c.  SCA  complements  a  number  of  other  analyses  commonly  performed 
in  a  system  development  program,  filling  in  for  "blind  spots" 
which  exist  in  all  analytical  techniques.  For  example,  it 
complements  an  FMECA  by  considering  procedural  errors  rather 
than  part  failures.  It  complements  the  test  program  by 
concentrating  on  situations  or  conditions  under  which  the 


system  might  not  work  rather  than  on  proving  that  the  system 
does  work  under  particular  controlled  input  condition.  Sec¬ 
tion  5.3  discusses  a  number  of  other  examples  of  this  com¬ 
plementary  nature  of  SCA  when  compared  to  more  conventional 
analyses  and  test  programs. 

5.1.1  Benefits  to  system  reliability.  SCA  benefits  the  system  reli¬ 
ability  program  by  identifying  potential  system  malfunctions  which  are 
not  the  result  of  part  failures.  The  more  conventional  methods  of 
reliability  prediction  and  control  concentrate  on  the  influence  of 
inherent  part  failure  rates  on  system  reliability.  More  often  than  not, 
inherent  or  "random"  part  failures  are  not  the  most  significant  con¬ 
tributor  to  observed  field  failures  of  a  system.  Design  oversights, 
procedural  problems,  and  interface  problems  cause  a  significant  number 
of  field  failures.  By  identifying  these  kinds  of  malfunctions,  SCA 
attacks  the  persistent  problem  that  exists  of  reconciling  reliability 
predictions  with  observed  field  failure  rates.  In  fact,  SCA  may  be 
indicated  when  a  large  number  of  unexplained  or  non-verifiable  field 
failures  have  been  experienced  on  a  program.  By  removing  operational 
failures,  glitches,  intermittent  failures  etc.,  system  uptime  can  be 
improved.  The  number  of  non-verifiable  failures  in  the  rework  cycle 
should  also  be  reduced,  further  increasing  operational  availability  of 
the  system. 

5.1.2  Benefits  to  system  safety.  SCA  is  considered  to  be  a  System 
Hazard  Analysis  by  MIL-STD-882,  and  it  definitely  performs  this  func¬ 
tion,  although  the  scope  of  SCA  is  considerably  broader.  Sneak  circuits 
can  be  hazardous,  and  their  removal  would  improve  system  safety  in  these 
cases.  The  performance  of  SCA  can  be  very  useful  in  performing  a 
comprehensive  Operating  Hazard  Analysis  (OHA)  or  Operation  and  Support 
Hazard  Analysis  (O&SHA)  because  it  identifies  hazards  which  result  from 
operational  or  procedural  causes. 

5.1.3.  Benefits  to  life  cycle  cost.  SCA  can  act  to  reduce  life  cycle 
cost  of  a  system  through  early  identification  and  control  of  system 
malfunctions.  The  removal  of  malfunctions  which  would  occur  during  the 
Operation  and  Maintenance  phase  is  particularly  effective  in  reducing 
life  cycle  costs.  Since  SCA  aims  at  a  class  of  problems  which  are  often 
overlooked  by  other  analyses  and  test  programs,  the  life  cycle  cost 
impact  of  SCA  can  be  very  real. 

5.2  Applicability  considerations.  SCA  must  be  considered  for  any 
Department  of  Defense  (DoD)  system  procurement  requiring  conformance  to 
MIl-STD-785.  An  SCA  should  be  performed  on  a  DoD  system  whenever  opera¬ 
tional  requirements  would  make  the  consequences  of  a  sneak  circuit 
unusually  severe.  This  decision  can  often  be  made  by  postulating  the 
most  severe  consequences  of  possible  unwanted  operational  modes  and 
comparing  the  resultant  cost  with  that  of  an  SCA.  Obviously  some  costs 
cannot  be  quantified  in  terms  of  dollars,  such  as  the  cost  of  human 


life,  or  a  significant  loss  of  defense  preparedness,  but  in  these  cases, 
performance  of  an  SCA  is  clearly  indicated.  SCA  should  be  performed 
when  one  or  more  of  the  following  conditions  is  present: 

a.  The  system  mission  is  critical,  to  the  point  that  operational 
malfunctions  cannot  oe  tolerated. 

b.  Improper  function  of  the  system  could  endanger  human  life  or 
substantially  damage  expensive  equipment. 

c.  The  system  complexity  is  such  that  sneak  circuits  may  go 
undetected  in  normal  testing. 

d.  Correction  of  sneak  conditions,  if  they  occurred  in  operation, 
would  be  difficult  or  impossible. 

e.  The  system  involves  interfaces  of  equipments  designed  or 
produced  by  a  number  of  different  contractors. 

f.  The  unique  features  of  an  independent  SCA  would  partially 
compensate  for  lack  of  thorough  design  evaluation  by  a  supplier. 

g.  Sneak  circuits  are  suspected  in  an  existing  system.  Before  a 
sneak  circuit  analysis  is  performed  a  failure  analysis  of  the 
malfunction(s)  should  be  performed  to  eliminate  causes  other 
than  sneaks,  such  as  electromagnetic  interference,  temperature 
sensitivity,  etc. 

5.2.1  Operational  anomalies.  Many  operational  systems  cevelop 
problems  which  are  intermittent  or  are  not  diagnostically  repeatable. 

The  application  of  SCA  is  a  viable  technique  for  identification  of 
potential  or  actual  causes  for  these  anomalies.  This  is  especially  true 
when  the  system  is  inaccessible  for  testing  and  diagnostic  checkout,  as 
for  example  a  spacecraft  that  has  been  launched.  Large  complex  systems 
are  difficult  to  analyze  without  the  aid  of  an  SCA  type  technique  to 
determine  the  possible  paths  which  could  cause  the  observed  problem. 

5.2.2  Application  to  electrical  and  electronic  systems.  SCA  is 
particularly  applicable  to  electrical  and  electronic  circuits  of  all 
types.  When  schedule,  time  and  cost  are  the  predominant  factors,  the 
analysis  may  be  limited  to  specific  critical  subsystems  or  functions. 

The  hardware  and  software  directly  related  to  specific  hazards,  safety, 
reliability,  test  anomalies  and  primary  system  functions  are  those  most 
often  selected  for  SCA. 

5.2.2. 1  Digital  circuitry.  SCA  applies  to  digital  circuits  of  vary¬ 
ing  complexity,  including  small  scale  integration  (SSI),  medium  scale 
integration  (MSI),  large  scale  integration  (LSI),  and  hybrids.  Standard 
integrated  circuits  (ICs)  allow  simplification  of  clue  lists  and  en¬ 
coding  procedures  for  data  processing.  Analysis  of  custom  LSI  and 


13 


hybrid  devices  generally  requires  the  IC  to  be  treated  in  the  same 
detailed  manner  as  a  circuit  card.  SCA  of  digital  circuits  can  reveal 
unexpected  cause  and  effect  relationships ,  timing  hazards,  reliability 
concerns,  and  other  related  problems. 

5. 2. 2. 2  Analog  circuitry.  SCA  of  analog  circuitry  can  reveal  un¬ 
expected  circuit  configurations  (modes),  unexpected  cause  and  effect 
relationships,  error  sources,  timing  (phase  shift  and  stability)  prob¬ 
lems,  reliability  concerns  and  other  related  problems. 

5. 2. 2. 3  Embedded  computer  software.  Many  new  systems  are  soft¬ 
ware  driven  or  hybrid,  that  is,  software  controlled  with  hardware 
control  backup.  This  situation  has  given  rise  to  the  development  of 
software  SCA  techniques  which  were  adapted  from  SCA  of  hardware.  The 
SCA  technique  can  be  applied  to  the  embedded  software  program  as  a 
separate  entity  (i.e.,  the  "stand-alone"  program),  or  to  the  integrated 
software/hardware  as  a  system.  There  are  definite  advantages  to 
applying  SCA  to  the  integrated  sof twa re/ hardware  system,  but  this 

form  of  embedded  code  analysis  is  not  widely  available  at  present.  The 
software  SCA  technique  may  also  be  applied  to  analyze  stand-alone 
(i.e.,  nonembedded)  software. 

5.2.3  Limitations  in  application  of  SCA.  SCA  has  been  successfully 
applied  to  a  variety  of  systems  and  has  been  responsible  for  removing 
many  potentially  costly  sneak  conditions  from  hardware.  Nevertheless, 
there  are  several  limitations  of  SCA  which  a  government  technical 
monitor  or  contracting  officer  must  consider  in  applying  SCA  to  a 
military  system  Some  of  these  limitations  are  inherent  to  the  SCA 
technique;  others  are  a  result  of  the  present  state  of  development 
and  availability  of  SCA  in  the  marketplace. 

5.2. 3.1  Lack  of  an  approved  SCA  method.  There  is  presently  no 
defined  government  approved  technique  for  performing  SCA.  As  a  re¬ 
sult,  techniques  may  vary  among  the  agencies  performing  it.  The 
thoroughness,  the  degree  and  quality  of  computer  aids,  the  level  of 
training  of  sneak  circuit  analysts,  the  validity  and  completeness  of  the 
"clues"  used  in  looking  for  sneak  conditions  will  differ  and  these 
factors  must  be  resolved  when  selecting  an  SCA  contractor. 

5. 2. 3. 2  Dependence  on  capabilities  of  the  analyst.  The  techniques, 
even  when  highly  automated  and  subjected  to  strict  quality  control, 
generally  depend  on  an  analyst  who  evaluates  each  path  or  network  and 
considers  the  conditions  under  which  that  path  may  occur.  This  process 
is  always  subject  to  human  error  and  may  permit  some  sneak  conditions  to 
slip  through. 
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5. 2. 3. 3  Concentration  on  topological  methods.  In  all  its  variations, 
SCA  tends  to  concentrate  on  topological  similarities  of  sneak  circuits. 
While  most  sneaks  can  be  found  in  this  manner,  not  all  possible  anomalous 
conditions  will  be  found  because  they  are  not  part  of  the  topology  of 
the  network  as  it  is  defined  by  the  system  drawings.  For  example,  the 
commonly  known  "sneak  circuit"  which  causes  a  transistor  amplifier  to 
oscillate  because  of  stray  capacitance  between  collector  and  base 
circuits  would  not  normally  be  found  in  an  SCA  because  the  stray  ele¬ 
ments  do  not  exist  in  the  system  drawing  definition. 

5. 2. 3. 4  Component  failure  modes  not  considered.  SCA  considers  that 
all  system  components  are  functioning  normally,  that  is,  they  are 
failure  free.  In  line  with  this  assumption,  the  effect  of  varying 
environments  on  component  failures  is  not  considered.  The  analysis  does 
consider  the  possible  "failure"  of  the  system  operator  to  provide 
correct  system  inputs,  but  not  component  failures.  Although  the  SCA 
often  identifies  single  point  failures,  it  cannot  be  considered  com¬ 
prehensive  in  this  regard. 

5. 2. 3. 5  Lack  of  available  cross-checks.  The  SCA  technique  has  found 
numerous  problems  in  mature  systems  that  were  overlooked  in  other 
analyses  and  test  programs,  but  it  is  virtually  impossible  to  determine 
whether  an  SCA  has  found  all  or  nearly  all  sneak  conditions  in  a  system. 
In  this  respect,  however,  it  is  difficult  to  determine  absolutely  that 
any  analysis  technique  has  completely  accomplished  its  purpose.  Despite 
this,  all  analyses,  including  SCA,  will  identify  problems  that  can  be 
corrected,  to  the  ultimate  enhancement  of  operational  availability. 

5. 2. 3. 6  Other  analyses  are  still  necessary.  SCA  provides  a  unique 
way  of  looking  for  potential  problems  in  systems  and  may  discover 
problems  which  would  more  properly  be  found  by  other  analyses,  such  as 
single  point  failures  which  are  also  considered  in  a  FMECA  or  excessive 
fan-out  which  is  considered  in  a  stress  analysis.  However,  SCA  must  not 
be  used  as  the  sole  reason  for  eliminating  these  other  analyses.  Other 
analyses  are  generally  done  to  specific  standards  which  define  both 
methods  and  reporting  requirements  so  that  results  properly  support 
other  activities  in  the  systems  acquisition  cycle.  For  example,  an  FMECA 
will  probably  be  used  to  support  a  maintenance  analysis  and  to  establish 
spares  requirements.  Although  an  SCA  may  consider  single  point  fail¬ 
ures,  this  is  done  more  incidentally  than  as  a  primary  objective  of  the 
analysis;  SCA  does  not  consider  all  or  even  most  part  failures.  Similar 
arguments  could  be  made  for  other  analyses  which  have  some  overlap  with 
SCA,  such  as  stress  analysis  or  hazards  analysis.  SCA  necessarily 
concentrates  most  heavily  on  those  areas  in  a  system  that  are  most 
likely  to  contain  sneak  circuits  or  conditions.  This  leads  to  differing 
levels  of  concentration  on  different  subsystems  or  their  intercon¬ 
nections.  Accordingly,  the  SCA  is  not  necessarily  comprehensive  in  the 
aspects  covered  by  other  analysis  techniques,  nor  is  it  intended  to  be. 
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5. 2. 3. 7  Cost.  The  performance  of  SCA  on  a  large  system  can  be  very 
costly.  For  this  reason  it  may  be  impossible,  within  funding  constraints, 
to  perform  a  detailed  SCA  of  a  complete  system.  In  such  cases,  the  SCA 
may  have  to  be  limited  to  a  system- level  analysis  or  to  the  analysis  of 
a  few  critical  subsystems. 

5.3  SCA  compared  to  other  analysis  techniques.  SCA  is  contrasted  to 
other  analyses  commonly  performed  in  a  reliability  and  safety  program  in 
a  number  of  important  ways.  SCA  generally  concentrates  on  the  inter¬ 
connections,  interrelationships,  and  interactions  of  system  components 
rather  than  on  the  components  themselves.  SCA  concentrates  more  on  what 
might  go  wrong  in  a  system  rather  than  on  verifying  that  it  works  right 
under  some  set  of  test  conditions.  The  SCA  technique  is  based  on  a 
comparison  with  other  systems  which  have  "gone  wrong",  not  because  of 
part  failures,  but  because  of  design  oversight  or  because  a  human 
operator  made  a  mistake.  The  consequence  of  this  subtly  different 
perspective  may  be  very  important,  because  it  tends  to  concentrate  on 
and  find  problems  which  may  be  hidden  from  the  perspectives  of  other 
analytical  techniques. 

5.3.1  Failure  modes,  effects,  and  criticality  analysis  (FMECA). 

FMECA  differs  from  SCA  in  that  it  predicts  and  quantifies  the  response 
of  a  system  to  failures  of  individual  parts  or  subsystems.  An  FMECA  is 
an  analysis  of  all  expected  failure  modes  and  their  effect  on  system 
performance.  FMECA  results  are  often  used  in  maintainability  predic¬ 
tions,  in  the  preparation  of  maintenance  dependency  charts,  and  to 
establish  sparing  requirements.  On  the  other  hand  SCA  considers  pos¬ 
sible  human  error  in  providing  system  inputs  while  FMECA  does  not.  In 
this  regard  the  two  types  of  analysis  tend  to  complement  one  another. 

5.3.2  Hazard  analysis.  The  general  objective  of  hazard  analysis  is 
the  identification  of  system  features  which  could  threaten  the  safety  of 
personnel  or  other  equipment.  MIL-STD-882  defines  several  different 
types  of  hazard  analyses  depending  on  the  state  of  development  of  the 
system  design,  the  portion  of  the  system  analyzed,  and  the  principal 
causative  agents  considered  to  create  hazards. 

5.3.2. 1  Preliminary  hazard  analysis  (PHA).  This  is  the  first  anal¬ 
ysis  of  the  system  and  is  designed  to  identify  gross  system  hazards  as 
the  basis  for  more  rigorous  and  detailed  analysis  later.  There  is 
little  overlap  between  SCA  and  PHA.  The  detailed  data  nase  needed  for 
SCA  is  normally  unavailable  at  the  time  a  PHA  is  performed. 

5. 3. 2. 2  Subsystem  hazard  analysis  (SSHA).  An  analysis  of  hazards 
associated  with  some  element  of  the  total  system  is  called  a  subsystem 
hazard  analysis.  MIL-STD-882  defines  three  types  of  SSHA:  fault  hazard 
analysis,  fault  tree  analysis,  and  sneak  circuit  analysis. 


5. 3.2.2. 1  Fault  hazard  analysis  (FHA).  The  FHA  is  an  inductive 
method  of  analysis  in  which  potential  hazard  modes  are  postulated  and 
their  effects  on  the  subsystem  are  determined.  The  method  overlaps  SCA 
in  that  hazard  modes  other  than  component  failure  are  analyzed. 

5. 3. 2. 2. 2  Fault  tree  analysis  (FTA).  The  FTA  is  a  deductive  method 
in  which  a  catastrophic  hazardous  end  result  is  postulated  and  the 
possible  events,  faults,  and  occurrences  which  might  lead  to  that  end 
event  are  determined.  FTA  also  overlaps  SCA  because  the  FTA  is  con¬ 
cerned  with  all  possible  faults,  including  component  failures  as  well 
as  operator  errors. 

5. 3. 2. 2. 3  Sneak  circuit  analysis  (SCA).  The  SCA  is  also  considered 
an  SSHA  by  MIL-STD-882,  although  the  technique  applies  equally  to  system 
hazard  analysis  (SHA)  discussed  below.  There  is  clearly  an  overlap 
between  the  intent  of  SCA  and  that  of  both  FHA  and  FTA;  each  is  intended 
to  discover  undesirable  system  operating  modes,  and  each  considers 
possible  causes;  however,  there  are  significant  differences.  There  is 

a  difference  in  emphasis;  FTA  and  FHA  include  and  emphasize  component 
failures  and  combinations  of  failures  with  other  events  as  causative 
agents,  SCA  does  not  comprehensively  address  failures.  There  is  a 
difference  in  objective;  FTA  and  FHA  are  concerned  with  hazardous  end 
result;  SCA  is  concerned  with  hazardous  results  but  also  with  any  other 
results  which  do  not  conform  to  design  intent.  There  is  a  difference  in 
perspective;  FHA  and  FTA  generally  consider  the  possible;  hazards  are 
all  considered  even  though  their  probability  is  remote.  SCA,  by  its 
comparison  to  other  systems  with  actual  sneak  circuits  in  them,  and  by 
its  reduced  concentration  in  areas  unlikely  to  have  sneak  conditions,  is 
concerned  more  with  the  probable.  Under  some  conditions,  FHA  and  FTA 
could  be  combined  with  SCA,  especially  if  the  analyses  were  done  by  the 
same  contractor.  The  configuration  data  base  is  common  to  both  anal¬ 
yses.  The  network  trees  generated  by  the  SCA  can  be  very  valuable  in 
evaluating  the  propagation  of  faults  in  a  system.  By  considering  non¬ 
single  point  failures  and  combinational  effects  at  those  points  where 
hazards  are  noted  in  the  SCA,  the  objectives  of  FHA  could  also  be 
achieved.  The  preparation  of  fault  trees  for  an  FTA  from  SCA  results 
would  then  be  relatively  straightforward  and  inexpensive. 

5. 3. 2. 3  System  hazard  analysis  (SHA).  System  hazard  analysis  is 
performed  on  subsystem  interfaces  to  investigate  safety  problem  areas  in 
the  total  system.  The  same  techniques  as  SSHA  are  applied.  Likewise, 
the  comments  regarding  the  similarities  and  differences  with  SCA  also 
apply  to  system  hazard  analysis.  With  proper  planning,  a  system  hazard 
analysis  could  be  cost  effectively  combined  with  the  SCA  for  the  system. 

5. 3. 2. 4  Operating  and  support  hazard  analysis  (O&SHA ) .  The  scope  of 
OSSHA  is  very  broad,  in  that  it  is  intended  to  identify  any  hazards 
which  might  occur  during  production,  installation,  maintenance,  testing, 
modification,  transportation,  storage,  operation,  training  and  disposal 
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of  a  system.  Because  of  this,  performance  of  SCA  cannot  obviate  the 
need  for  O&SHA.  SCA  can  be  used  in  support  of  O&SHA  to  identify  poten¬ 
tial  hazards  and  to  analyze  the  interconnection  of  the  system  within  a 
larger  system  and  the  interfaces  with  test  and  ground  support  equipment. 

5.3.3  Stress  analysis.  Stress  analysis  is  performed  to  assure  that 
all  components  and  piece  parts  in  a  system  are  operated  within  their 
maximum  ratings  or  limited  to  some  more  conservative  derating  design 
value.  An  SCA  analyst  should  consider  part  stress  in  specific  instances 
where  it  appears  to  be  a  potential  problem  and  should  report  his  findings. 
However,  the  regimen  and  meticulous  attention  paid  to  the  stresses  on 

all  piece  parts  during  a  stress  analysis  is  not  a  part  of  SCA.  There¬ 
fore  performance  of  SCA  should  never  be  used  to  justify  deletion  of  a 
stress  analysis  on  a  system. 

5.3.4  Worst-case  analysis.  Some  systems  or  subsystems  are  subjected 
to  a  worst-case  analysis  which  considers  build-up  of  component  and  input 
tolerances,  worst-case  temperature  variations,  aging  effects,  and  a 
variety  of  other  factors  in  determining  that  a  design  will  function 
within  design  limits  under  all  conditions.  SCA  generally  has  little 
overlap  with  worst-case  analysis  and  the  performance  of  SCA  does  not 
eliminate  the  need  for  worst-case  analysis  if  it  is  otherwise  needed.  A 
possible  overlap  with  digital  SCA  exists,  however,  in  the  reverse 
direction.  If  a  thorough  worst-case  analysis  were  performed  on  a  purely 
digital  system  and  the  analysis  considered  variations  in  all  possible 
system  inputs,  worst-case  signal  timing,  and  worst-case  loading,  the 
performance  of  an  SCA  would  probably  not  be  justified. 

5.3.5  Human  factors  analysis.  The  consideration  of  human  factors  in 
the  design  of  military  systems  is  covered  in  M IL- STD- 1 472 .  The  standard 
defines  detailed  requirements  for  the  proper  design  of  components  and 
systems  so  that  they  can  be  successfully  operated  by  humans.  The  intent 
of  SCA  to  find  sneak  labels,  sneak  indications,  logical  inconsistencies, 
etc.,  recognizes  the  possibility  that  humans  can  make  errors  when 
operating  a  complex  system.  SCA  of  all  types  should  be  performed  with 
the  standards  of  MIL-STD-1472  in  mind.  SCA  cannot,  however,  be  con¬ 
sidered  a  replacement  for  a  thorough  human  factors  analysis;  neither 
the  emphasis  nor  the  intensity  is  sufficient  to  ensure  that  all  human 
factors  have  been  considered.  On  the  other  hand,  SCA  results  can  be 
very  useful  in  identifying  possible  human  engineering  problem  situations 
which  can  then  be  subjected  to  more  intensive  human  factors  analysis. 

5.3.6  The  SCA  and  test  programs.  Testing  can  never  obviate  the  need 
for  SCA.  Testing  is  intended  to  show  that  the  system  functions  properly 
when  the  proper  system  inputs  are  made.  SCA,  on  the  other  hand,  looks 
for  plausible  situations  and  combinations  of  inputs  which  may  cause  the 
system  to  work  incorrectly.  Testing  is  almost  always  repetitive;  if  a 
problem  exists  when  a  certain  combination  of  inputs  occurs,  repeating  a 
set  of  tests  that  do  not  contain  the  combination  will  never  detect  the 
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problem.  In  addition,  connection  to  the  tester  can  itself  be  the  source 
of  sneak  circuits.  Therefore,  the  tester  connection  to  the  unit  under 
test  (UUT)  should  be  considered  a  likely  candidate  for  an  SCA,  and 
should  definitely  be  performed  if  there  are  possible  hazardous  con¬ 
ditions  which  could  result  from  testing.  An  SCA  which  also  considers 
failure  modes  of  the  UUT  could  be  very  useful  in  finding  failure  modes 
which  might  go  undetected  by  normal  test  sequences. 

5. 3.6.1  Software  test  programs.  Software  SCA  attacks  the  same 
problems  as  do  the  software  quality  assurance,  QA  testing,  and  veri¬ 
fication  and  validation  (V&V)  functions,  that  is  the  achievement  of 
software  that  meets  performance  requirements  with  no  undesirable 
operating  modes  or  sneak  conditions  such  as  unresolved  cod°  loops, 
inaccessible  code,  or  unused  subroutine  entries  or  exits,  lhe  impact  of 
MIL-STD-1679  in  achieving  widespread  use  of  structured  coding  tech¬ 
niques,  top-down  design  principles,  and  performance  requirement  trace- 
ability  has  yet  to  be  assessed.  The  degree  of  sophistication  of  code 
compilers  and  code  analyzers  used  in  modern  computers  is  also  increasing 
rapidly.  All  of  these  factors  will  have  an  impact  on  the  advisability 
of  performing  the  SCA  on  a  particular  software  program.  If  modern 
coding  practices,  compilers,  a  thorough  and  pervasive  QA  program,  and 
independent  V&V  have  been  applied,  the  need  for  software  SCA  certainly 
diminishes.  However,  there  is  still  much  software  being  produced  which 
has  not  had  the  benefit  of  these  practices.  Embedded  software  which 
interfaces  directly  with  hardware  on  which  SCA  is  being  performed  is 
another  likely  candidate  for  software  SCA.  In  both  of  these  cases, 
software  SCA  should  be  considered  as  a  good  means  of  augmenting  a  less 
than  ideal  test  program. 

5.4  Trade-offs.  The  potential  benefits  of  an  SCA  will  always  be 
weighed  against  other  program  considerations.  Factors  such  as  cost, 
schedule,  the  existence  of  other  analyses,  the  availability  of  data, 
the  ease  with  which  available  system  data  can  be  interfaced  with  SCA 
programs,  and  the  availability  of  a  qualified  SCA  contractor,  must  all 
be  considered.  When  it  is  considered  that  SCA  can  be  tailored  to  fit 
the  needs  of  most  systems  by  applying  it  only  to  system- level  inter¬ 
connections  or  only  to  the  more  critical  subsystems,  an  argument  against 
SCA  based  strictly  on  cost  is  not  really  defensible.  While  there  is 
some  overlap  between  SCA  and  other  analyses,  performance  of  most  other 
analyses  and  test  programs  cannot  substitute  for  an  SCA  (and  vice 
versa) . 


6.0  PERFORMING  ACTIVITY  AND  OTHER  PARTICIPANTS 


6.1  General .  One  factor  in  assuring  that  an  effective  SCA  is  per¬ 
formed  is  the  determination  of  the  activity  which  is  to  actually  conduct 
the  analysis.  This  determination  should  include  consideration  of  many 
facets,  all  of  which  are  variable  and  will  be  different  for  each  given 
situation.  Similarly,  it  will  be  necessary  to  determine  what  activity 
can  most  effectively  order  and  manage  the  effort,  as  well  as  to  desig¬ 
nate  the  other  participants  who  are  to  be  involved  in  establishing  the 
scope  or  depth  of  the  analysis,  evaluating  the  results,  devising  cor¬ 
rective  actions  and  the  implementation  thereof,  and  other  related 
aspects. 

6.2  Performing  activity.  In  the  designation  of  the  activity  to 
perform  the  SCA,  in  order to  assure  maximum  effectiveness,  the  following 
considerations  should  be  evaluated:  (1)  capability,  (2)  costs,  (3)  level 
of  program  involvement,  and  (4)  merits  of  independent  analysis  versus 
"in-house"  analysis.  Additional  considerations  may  also  apply  in  a 
given  situation. 

6.2.1  Capability.  All  activities  engaged  in  design  and  development 
will  have  some  capability  in  SCA,  whether  or  not  they  refer  to  it  by 
that  nomenclature.  Only  a  limited  number  of  activities,  however,  will 
have  developed  the  sophisticated  computer  programs  and  structured  SCA 
techniques  that  are  essential  to  detailed  analysis  of  the  more  complex 
systems.  Accordingly,  the  selection  of  the  performing  activity  will  be 
substantially  influenced  by  the  scope  of  the  analysis.  Methods  for 
assessment  of  prospective  SCA  contractors  capabilities  a^e  discussed  in 
Section  8  herein. 

6.2.2  Costs.  Potential  costs  for  performance  of  the  SCA  will  typi¬ 
cally  vary  considerably  between  prospective  activities.  For  example, 
the  contractor  who  is  to  perform  other  analyses  will  have  structured  the 
system  data  base  (such  as  flowcharts,  logic  timing,  block  diagrams, 
etc.)  much  of  which  is  directly  applicable  to  the  SCA.  Additionally, 
the  development  contractor  will  have  ready  access  to  all  system  docu¬ 
mentation  which  should  result  in  less  cost  than  compilation  and  dis¬ 
semination  to  a  second  party.  On  the  other  hand,  a  second  party  may 
have  in  place  systemized  techniques  and  qualified  analysts,  which  will 
reduce  costs  associated  with  development  of  such  capability.  Some  guid¬ 
ance  for  estimating  and  evaluating  costs  is  provided  in  Section  9 
herein. 

6.2.3  Program  Involvement.  The  level  of  involvement  in  the  development 
of  the  system  may  influence  the  selection  of  the  activity  to  perform  the 
SCA.  Because  of  the  nature  and  purpose  of  the  SCA,  it  would  generally 

be  inappropriate  to  task  several  subcontractors  to  perform  the  analysis 
on  the  subsystem  under  their  cognizance.  From  this  standpoint,  the 
prime  development  or  integrating  contractor  is  best  positioned  to  have 
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the  necessary  total  overview  (the  prime  development  or  integrating 
contractor  may  be  a  government  agency).  However,  depending  on  indivi¬ 
dual  circumstances,  the  activity  best  positioned  to  command  a  total 
overview  may  not  have  in  place  the  requisite  capability. 

6.2.4  Independent  analysis.  Traditionally,  system  effectiveness 
analyses  are  performed  by  other  than  the  designers  (reliability  groups, 
safety  groups,  etc.).  The  effectiveness  of  this  approach  has  been  amply 
demonstrated.  It  is  effective  because  it  is  more  likely  to  be  objec¬ 
tive,  plus  it  provides  a  "double  check"  which  is  always  desirable. 

Those  directly  involved  in  the  design  process  may  be  "too  close  to  the 
trees  to  see  the  forest."  This  factor  strongly  suggests  that  an  in¬ 
dependent  contractor  should  be  considered  for  the  performance  of  the 
SCA,  but  does  not  rule  out  performance  by  an  independent  group  within 
the  development  contractor's  organization.  One  aspect  that  must  be 
given  careful  consideration  is  the  feasibility  of  interchange  of  data, 
both  the  preliminary  data  base  (including  analysis  tools  such  as  flow 
charts,  timing  sequences,  block  diagrams,  etc.),  and  the  data  outputs 
from  the  SCA.  An  independent  contractor  may  consider  the  details  of  the 
analysis  (which  are  essential  to  evaluation  of  the  thoroughness  and 
correctness)  to  be  proprietary. 

6.3  Ordering  activity.  Depending  on  circumstances,  the  activity  to 
order  and  administer  the  SCA  may  be  a  government  organization  or  a 
prime  contractor.  Consideration  should  be  given  to  that  activity  best 
qualified  to  negotiate  the  effort,  and  to  evaluate  the  results.  As  a 
minimum,  the  ordering  activity  must  have  personnel  who  are  thoroughly 
conversant  with  the  objectives  of  the  SCA  and  have  at  least  a  rudi¬ 
mentary  knowledge  of  the  techniques  involved.  Further,  the  ordering 
activity  must  have  technically  qualified  specialists  who  are  familiar 
with  the  system(s)  involved,  and  who  are  capable  of  assessment  of  the 
analysis  results  and  their  disposition  (no  action  required,  design 
change  required,  procedure  change  required,  etc.). 

6.4  Other  participants  Typically,  the  performance  of  the  SCA  will 
necessarily  involve  several  organizations  or  groups  within  a  given 
organization.  Before  initiating  the  SCA,  such  organizations,  groups,  and 
individuals  should  be  identified,  and  their  responsibilities  clearly 
defined. 

6.4.1  Establishment  of  criteria.  At  the  offset  it  will  be  necessary 
to  determine  the  extent  and  scope  of  the  SCA,  determine  the  activity  to 
perform  the  analysis,  determine  the  schedule,  and  negotiate  all  aspects. 
This  will  involve  contract  administrators,  program  management,  and 
technical  personnel  from  each  activity  participating. 


6.4.2  Inputs  to  the  analysis.  Design  disclosure  documentation 
(drawings,  schematics,  specifications,  etc.),  as  well  as  baseline  data 
such  as  flowcharts,  block  diagrams,  etc.,  will  be  required.  This  will 
involve  configuration  management  as  well  as  technical  specialists. 
Negotiation  with  subcontractors  may  be  necessary  in  order  to  gather  all 
necessary  detail . 

6.4.3  Coordination  with  other  efforts.  Continuous  coordination  will 
be  required  to  advise  the  performing  activity  of  changes  as  they  occur 
as  well  as  to  supply  him  with  supplemental  data  he  may  require.  If  the 
effort  is  properly  planned,  interim  reports  will  be  provided,  especially 
when  any  potential  problems  are  identified. 

6.4.4  Evaluation  of  the  results.  The  results  of  the  analysis  must  be 
evaluated,  incrementally,  and  at  the  conclusion  of  the  effort.  This  is 
necessary  not  only  to  assess  the  validity  of  the  findings,  but  finally 
to  determine  if  the  performing  activity  has  satisfactorily  completed  the 
effort. 

6.4.5  Utilization  of  the  results.  Determinations  must  be  made  as  to 
actions  to  be  taken  based  on  the  results  of  the  analysis,  including 
implementation  and  validation  of  any  changes  required.  This  may  involve 
negotiations  with  the  performing  activity  to  repeat  certain  portions  of 
the  analysis. 
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7.0  SCHEDULING  THE  SCA 


7.1  General .  Scheduling  of  the  SCA  for  optimum  effectiveness  is 
paced  by  the  design  process.  There  will  be  an  optimum  point  in  time  for 
every  program,  based  almost  exclusively  on  the  degree  of  design  maturity, 
but  this  point  will  typically  be  somewhat  difficult  to  identify.  Per¬ 
formance  of  the  SCA  too  early  in  the  development  process  may  result  in 
penalties  because  of  insufficiently  mature  design  data,  and  thus  wasted 
effort  in  attempting  to  structure  the  data  base  and  in  analysis  of  an 
evolving  design.  Conversely,  if  the  SCA  is  delayed  too  long,  changes 
may  be  very  costly  in  terms  of  dollars  and  schedules;  this  would  be 
especially  true  where  early  commitment  for  long  lead  time  items  is 
necessary  (and  this  is  more  often  than  not  the  case,  especially  for 
highly  complex  systems). 

7.2  Multiple  subcontractors.  The  more  participants  involved  in  the 
development  program,  the  more  difficult  it  becomes  to  optimize  the  SCA 
schedule.  Inevitably,  the  different  subcontractor's  designs  will  be  in 
different  stages  of  maturity  and  the  documentation  will  be  in  varying 
phases  of  completion.  Early  consideration  of  this  aspect  by  program 
management  will,  however,  permit  establishment  of  a  milestone  at  which 
all  participants  must  have  at  least  semifinal  documentation  available. 
Although  the  timing  will  never  be  as  well  coordinated  as  would  be 
desired,  early  recognition  of  the  need  for  such  a  milestone  should  serve 
to  alleviate  the  problem,  by  improving  the  probability  of  having  the 
necessary  data  to  initiate  the  SCA  at  the  appropriate  time  in  the 
acquisition  cycle. 

7.3  Acquisition  phases.  The  DoD  acquisition  phases  are  as  depicted 
in  Figure  2,  which  also  shows  the  preferred  scheduling  of  SCA  activities 
as  related  to  the  acquisition  milestones.  This  of  course  represents  a 
somewhat  idealized  situation  and  can  only  be  considered  a  general  guide, 
if  for  no  other  reason  than  the  fact  that  programs  rarely  track  the 
acquisition  milestones  precisely.  Generally,  the  SCA  related  activities 
are  as  follows: 

a.  Planning  and  scoping 

b.  Data  base  assimilation 

c.  Performance  of  the  analysis 

d.  Corrective  action  and  validation 

e.  Monitoring  changes 

f.  Problem  investigation 


FIGURE  2.  Phasing  of  the  SCA  within  the  DoD  System  Acquisition  Process 


7.3.1  Planning  and  scoping.  These  activities  include  the  decision  as 
to  whether  or  not  to  require  the  SCA  for  the  program  of  interest,  and 
establishment  of  the  level  or  scope  of  the  analysis.  Considerations  as 
to  the  designation  or  selection  of  the  activity  to  perform  the  SCA 
should  also  be  initiated  in  this  time  frame. 

7.3.2  Data  base  assimilation.  During  this  period  milestones  should 
be  established  for  delivery  of  requisite  documentation  and  data  by  all 
applicable  participants.  A  configuration  management  program  will  be 
required  to  ensure  that  all  pertinent  data  will  be  available  and  under 
formal  change  control .  As  documentation  becomes  available,  baseline  data 
such  as  block  diagrams,  flowcharts,  etc.  (which  define  the  system  in  a 
form  amenable  to  the  performance  of  the  analysis)  should  be  prepared. 
Generally,  these  baseline  data  will  be  fed  back  to  the  ordering  acti¬ 
vity  for  validation  of  the  accuracy  of  the  system  description  and  any 
assumptions  associated  therewith,  before  the  actual  analysis  is 
initiated. 

7.3.3  Performance  of  the  analysis.  As  indicated  in  Figure  2,  the 
detailed  analysis  results  should  be  available  in  time  for  the  Critical 
Design  Review  (CDR),  as  an  input  to  the  decision  for  the  transition  to 
the  production  phase,  and  the  associated  hardware  commitments.  At  the 
very  latest,  the  results  must  be  available  at  Milestone  III,  if  they  are 
to  be  useful. 

7.3.4  Corrective  action  and  validation.  These  activities  should  take 
place  more  or  less  in  parallel  with  the  analysis,  given  that  the  anal¬ 
ysis  results  are  reported  incrementally,  which  should  be  mandatory, 
except  for  possibly  the  situation  where  the  analysis  is  very  limited  in 
scope  or  is  being  performed  on  a  relatively  simple  system.  Generally, 
any  corrective  actions  that  are  established  should  be  fed  back  to  the 
SCA  analyst  for  incorporation  in  his  model  and  revalidation. 

7.3.5  Monitoring  changes.  Changes  to  the  hardware  or  the  software 
will  occur  throughout  the  development  phases,  and  typically  throughout 
the  production/deployment  phases.  Those  changes  occurring  during  the 
conduct  of  the  SCA  should  be  fed  back  to  the  SCA  performing  activity 
immediately.  Subsequent  to  completion  of  the  SCA,  evaluation  of  pro¬ 
posed  changes  should  be  relatively  inexpensive  if  provision  has  been 
made  to  maintain  the  baseline  data,  system  models,  etc. 

7.3.6  Problem  investigation.  Not  infrequently,  problems  occur  during 
both  development  and  production/deployment  of  military  systems  for  which 
the  explanation  might  be  forthcoming  from  a  limited  SCA.  Problems  of  an 
intermittent  nature  are  particularly  good  candidates  for  the  SCA.  As 
with  change  monitoring,  this  should  be  relatively  inexpensive  if  the 
baseline  data  are  intact. 
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7.4  Non-DSARC  programs.  Programs  not  under  formal  DSARC  control 
(generally  programs  where  the  dollar  commitment  to  development  or 
production  does  not  exceed  certain  thresholds)  may  also  be  candidates 
for  SCA,  if  they  meet  some  of  the  criteria  set  forth  in  Section  5 
herein.  In  these  instances,  milestones  generally  equivalent  to  those  of 
the  DSARC  should  be  available  for  guidance  in  planning  and  implementing 
the  SCA.  The  same  considerations  of  design/development  status  will 
apply. 

7.5  Alternative  scheduling  considerations.  These  discussions  and 
guidelines  are  not  intended  tc  cover  every  possible  situation  where  the 
SCA  techniques  may  be  applicable,  and  tailoring  to  meet  the  needs  of 
each  individual  situation  is  to  be  encouraged.  Section  8  of  this 
handbook  discusses  some  alternatives  that  may  be  useful  in  contracting 
for  and  managing  the  SCA. 
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8.0  CONTRACT  MANAGEMENT 


8.1  General .  Previously  in  this  guide  the  SCA  has  been  described, 
and  the  many  factors  influencing  the  decision  as  to  whether  or  not  it 
might  be  applicable  or  beneficial  as  applied  to  a  given  program  have 
been  discussed.  Scheduling  of  the  SCA  within  the  systems-acquisition 
cycle  and  the  selection  of  the  performing  activity  have  also  been 
addressed.  It  is  the  intent  of  this  section  to  present  suggestions  and 
guidelines  with  respect  to  contracting  for  and  management  of  the  effort. 
Because  of  the  many  variables,  it  would  not  be  appropriate  to  specify 
exact  methods  of  contracting  for,  nor  performance  of,  the  SCA;  the 
intent  rather  is  to  identify  those  aspects  that  should  be  considered  in 
making  these  determinations  in  a  given  specific  situation. 

8.1.1  Preliminary  tasks.  As  discussed  previously,  particularly  in 
Sections  6.0  and  7.0  herein,  there  are  a  number  of  matters  to  be  re¬ 
solved  before  selecting  the  type  of  contract  that  would  be  most  suit¬ 
able  in  a  given  situation.  Some  of  these  will  have  been  addressed,  at 
least  in  part,  in  the  process  of  determining  whether  or  not  to  require 
the  SCA,  but  they  will  need  to  be  investigated  in  more  detail  in  order 
to  establish  contractual  provisions,  and  a  plan  for  the  management  of 
the  effort.  7nese  matters  include,  but  are  not  necessarily  limited  to, 
the  following: 

a.  Determine  scope  or  extent  of  analysis 

b.  Determine  what  data  bases  will  be  available 

c.  Determine  schedules  for  design  documentation  availability 

d.  Determine  prospective  performing  activities 

e.  Determine  participants  and  responsibilities 

8.1.2  Statement  of  requirements.  Unlike  most  conventional  analytical 
techniques,  there  exists  no  documented  procedure  generally  accepted  or 
recognized  by  the  industry  or  the  Government  for  the  SCA.  Thus,  re¬ 
quirements  must  be  stated  in  general  terms.  Because  there  are  a  number 
of  methodologies  in  use,  it  would  be  inappropriate  to  be  specific 
regarding  the  method,  even  if  this  were  possible.  The  emphasis  should 
accordingly  be  on  the  results  expected.  In  this  regard,  it  is  of  para¬ 
mount  importance  that  the  performing  activity  be  required  to  submit  (or 
make  available  for  inspection)  sufficient  data  to  illustrate  that  the 
analysis  has  been  complete  to  the  extent  required,  and  to  provide 
assurance  that  all  potential  sneak  conditions  have  been  identified. 

8.2  Contracting  for  the  SCA.  The  necessity  for  request  for  proposals 
(RFP),  purchase  orders,  or  contracts  to  be  very  explicit  is  particularly 
important  in  the  case  of  the  SCA.  Because  the  SCA  is  not  well  defined, 
this  will  not  be  an  easy  objective  to  realize,  but  it  is  essential.  In 
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this  context,  RFPs  should  require  that  responses  (proposals)  clearly 
indicate  the  types  and  extent  of  analysis  to  be  performed  and  that  the 
methodology  be  fully  defined  so  that  the  procuring  activity  may  be 
assured  that  the  contractor  understands  the  intent  of  the  procurement. 

In  most  cases,  supplemental  pre-award  conferences  between  the  procuring 
activity  and  the  prospective  contractors )  will  be  required. 

8.2.1  Types  of  contracts.  A  wide  selection  of  types  of  contracts  is 
available  to  the  contracting  parties.  The  respective  contract  types 
vary  as  to  (1)  the  degree  and  timing  of  responsibility  assumed  by  the 
contractor  for  the  costs  of  performance,  and  (2)  the  amount  and  type  of 
profit  incentive  offered  the  contractor  to  achieve  or  exceed  specified 
standards  or  goals.  With  regard  to  degree  of  cost  responsibility,  the 
various  types  of  contracts  may  be  arranged  in  order  of  decreasing 
contractor  responsibility  for  the  costs  of  performance.  At  one  end  is 
the  firm-fixed-price  contract  under  which  the  parties  agree  that  the 
contractor  assumes  full  cost  responsibility.  At  the  other  end  of  this 
range  is  the  cost-plus-a-fixed-fee  contract  where  profit,  rather  than 
the  price,  is  fixed  and  the  contractor's  cost  responsibility  is  there¬ 
fore  minimal.  In  between  are  the  various  incentive  contracts  which  pro¬ 
vide  for  a  varying  degree  of  contractor  cost  responsibility,  depending 
upon  the  degree  of  uncertainty  involved  in  contract  performance.  The 
specific  type  of  contract  should  be  determined  by  the  degree  of  risk  in 
contract  performance.  When  the  risk  is  minimal  or  can  be  predicted 
with  an  acceptable  degree  of  certainty,  a  firm-fixed-price  contract  is 
preferred.  However,  as  the  uncertainties  become  more  significant,  other 
fixed  price  or  cost  type  contracts  should  be  employed  to  accommodate 
these  uncertainties  and  to  better  match  risk  and  cost  by  the  SCA 
contractor. 

8.2.2  Contracting  in  phases.  Consideration  should  be  given  to  the 
feasibility  of  contracting  for  the  SCA  in  a  progression  of  discrete 
phases,  especially  for  larger  or  more  complex  situations.  By  this 
approach,  it  should  be  possible  to  manage  the  effort  more  effectively 
because  of  definitive  milestones  that  will  be  inherent  to  the  process. 
Accordingly,  risks  for  both  the  ordering  activity  and  the  performing 
activity  should  be  reduced.  Such  a  plan  could  take  the  following  form: 

a.  Phase  1 :  The  initial  phase  would  include  refinement  of  and 
agree-ment  on  the  system  description  (based  on  scoping  the 
effort)  and  preliminary  data  base  tools  (such  as  flow  and 
logic  diagrams,  etc.).  The  approach  to  be  used  in  the  actual 
analysis  would  be  defined.  For  more  complex  or  more  critical 
systems,  it  would  be  desirable  to  have  two  or  more  contractors 
perform  the  Phase  1  effort  independently  but  concurrently. 

b.  Phase  2:  During  this  phase  the  SCA  would  be  performed  at 
system/  subsystem  level  by  the  contractor  selected  at  the 
completion  of  Phase  1.  The  objective  would  be  to  identify  top 
level  problems  and  establish  a  plan  for  more  lower  level 
analysis  in  a  selective  manner. 
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c.  Phase  3:  This  phase  would  include  in-depth  analysis  to  the 
extent  established  by  Phase  2.  Reevaluation  of  corrective 
actions  resulting  from  potential  problems  identified  in  this 
and  previous  phases  would  be  included  as  applicable. 

d.  Phase  4.  During  this  phase  monitoring  and  evaluation  of 
changes  and  problem  investigations  would  be  performed  on  an  as 
required  basis. 

8.2.3  Reports  and  other  data  items.  The  exact  types  and  formats  of 
reports  and  other  data  items  should  not  be  initially  stipulated  by  the 
ordering  activity  but  should  be  proposed  by  the  prospective  performing 
contractors  subject  to  negotiation  prior  to  contract  award.  Requiring 
the  contractor  to  conform  to  arbitrary  formats  is  counterproductive  in 
terms  of  cost  effectiveness,  and  serves  no  useful  purpose,  so  long  as 
sufficient  information  is  presented  to  permit  evaluation  of  the  pro¬ 
blems,  and  to  assure  that  the  analysis  has  been  completed  to  the  extent 
and  depth  prescribed.  Requests  for  proposals  (RFPs)  must,  however,  be 
explicit  in  requiring  prospective  contractors  to  describe  in  detail 
their  reporting  plans  and  procedures,  which  then  become  contractual 
obligations  upon  award. 

8.3  Evaluating  and  monitoring  the  SCA.  This  activity  consists  of 
three  principal  steps]  ( 1 )  evaluation  and  selection  of  the  performing 
activity;  (2)  monitoring  the  SCA  effort  during  performance;  and  (3) 
evaluating  the  final  results. 

8.3.1  Selecting  an  SCA  contractor.  Prior  to  awarding  an  SCA  con¬ 
tract,  the  technical  monitor  will  be  called  upon  to  evaluate  competing 
SCA  techniques  proposed  by  different  activities,  and  select  the  most 
appropriate  for  the  system  under  consideration.  Under  present  con¬ 
ditions,  the  selection  among  candidate  SCA  techniques  must  be  made  via 
an  evaluation  of  their  effectiveness  in  detecting  sneak  conditions, 
rather  than  by  a  detailed  specification  of  the  steps  to  be  taken  in 
performing  the  analysis. 

8. 3. 1.1  Evaluating  SCA  techniques  In  declaring  his  capability,  or 
responding  to  an  RFP,  the  contractor  should  be  required  to  provide  a 
detailed  outline  of  the  SCA  procedure  to  be  used,  withholding  any 
proprietary  procedures  but  indicating  in  general  what  these  entail.  The 
bid  or  proposal  should  include  a  formal  justification  of  the  proposed 
techniques,  consisting  of  a  theoretical  discussion  of  the  validity  of 
the  technique,  supposed  advantages,  any  known  limitations,  and  a  formal 
report  detailing  the  results  of  any  tests  run  to  establish  its  validity 
on  either  real  or  test  cases.  Reports  demonstrating  successful  previous 
applications  of  the  proposed  SCA  procedures  should  also  form  a  part  of 
the  bid  package  if  they  are  available.  The  technical  monitor  should 
evaluate  the  competing  proposals  based  on  their  anticipated  effective¬ 
ness  on  the  system  under  consideration  as  well  as  any  other  factors 
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which  are  pertinent  to  the  procurement.  It  should  be  remembered  in  this 
regard  that  new  or  innovative  SCA  techniques  will  not  have  as  strong  a 
historical  basis  as  more  established  techniques;  however  this  should  not 
be  the  sole  reason  for  rejecting  such  procedures;  innovation  involves 
some  risk.  The  evaluation  of  competing  proposals  may  involve  on-site 
inspection  of  supplier's  facilities  to  review  data  processing  capabilities, 
personnel,  and  quality  assurance  procedures. 

8. 3. 1.2  Data  to  be  provided.  A  critical  aspect  in  the  evaluation  of 
proposals  is  the  necessity  to  ensure  that  the  proposed  deliverable 
output  data  from  the  analysis  will  be  sufficiently  comprehensive  to 
permit  a  determination  as  to  whether  or  not  the  analysis  was  complete. 
Merely  reporting  discrepancies  or  problems  is  not  sufficient  for  this 
purpose.  Notwithstanding  the  possible  proprietary  nature  of  certain 
types  of  material,  the  prospective  performing  activity  must  declare  his 
willingness  to  provide  such  material  if  this  is  necessary  in  order  to 
permit  an  adequate  evaluation  of  the  results.  Such  material  might 
include  worksheets,  network  trees,  topographs,  or  similar  data  that 
would  illustrate  the  actual  extent  of  the  analysis  (such  as  the  cir¬ 
cuits  that  were  actually  analyzed,  specific  components  considered  in  the 
analysis,  assumptions  made  regarding  circuit  states  input/output  con¬ 
ditions,  etc.).  There  is  little  benefit  to  selecting  the  performing 
activity  based  on  cost,  assumed  capability,  or  other  factors,  if  it  is 
not  possible  to  conclusively  determine  (upon  completion)  that  the 
objectives  were  realized. 

8.3.2  Monitoring  SCA  performance.  Monitoring  SCA  performance  must 
begin  by  establishing  provisions  in  the  SCA  contract  which  will  facil¬ 
itate  monitoring  throughout  the  effort.  Results  of  any  trade-offs 
(e.g.,  cost,  schedule,  etc.)  incorporated  as  a  result  of  scoping  the  SCA 
effort  deserve  special  attention.  Incidental  features  which  are  to  be 
included  in  the  analysis  should  definitely  be  specified  contractual ly. 

For  example,  assurance  that  analysts  look  for  single  failure  points, 
part  overstress,  lack  of  transient  suppression  on  relays,  etc.,  can  only 
be  obtained  if  specifically  called  for  in  the  contract.  Further  as¬ 
surance  of  proper  contractor  performance  can  be  gained  by  (1)  contrac¬ 
tually  requiring  periodic  technical  and  final  progress  reports,  (2)  by 
requiring  government  involvement  in  the  final  partitioning  process,  and 
(3)  by  separate  funding  of  SCA  phases  with  provisions  for  redirection 
between  contract  phases,  if  necessary.  Periodic  on-site  surveys  may 
also  be  desirable.  The  Government  monitors  should  review  technical 
progress  against  expenditures,  evaluate  interim  results,  and  provide 
technical  liaison  with  the  design  activity  on  any  problems  identified. 

8.3.3  Evaluating  SCA  results.  Every  SCA  contract  must  require  a 
final  report  detailing  SCA  results,  sneak  circuit  conditions  found,  and 
the  recommended  disposition  for  any  problems  identified.  If  the 
performing  activity  is  to  be  involved  in  the  resolution  of  problems,  the 
report  should  include  final  disposition  of  any  problems  noted.  The 
contract  must  also  require  that  any  computerized  system  data  base  used 
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in  the  analysis  be  delivered  to  the  Government  or  retained  by  the 
contractor  for  the  duration  of  the  program.  In  this  way,  the  data  base 
will  be  available  to  evaluate  later  modifications  to  the  system.  The 
Government  monitors  must  assure  that  all  contractual,  contract  data 
requirements  list  (CDRL),  and  data  item  description  (DID)  requirements 
have  been  met.  Problem  identification,  recommended  solutions  and 
dispositions  should  be  reviewed  for  appropriateness  and  adequacy.  The 
monitors  must  assure  that  the  configuration  used  in  the  SCA  is  ade¬ 
quately  documented,  including  any  engineering  change  notice  (ECN)  or 
marked-up  drawings,  and  must  assure  that  any  computerized  data  base  is 
retained.  Any  worksheets  which  have  been  delivered  as  part  of  DID 
requirements  should  be  reviewed  for  completeness  and  depth  of  analysis. 

8.4  Data  Considerations.  The  SCA  contract  should  include  provisions 
for  the  control  of  system  data  during  the  course  of  the  effort.  Data 
considerations  include  (1)  specifying  the  required  input  data, 

(2)  special  formatting  requirements,  (3)  security,  (4)  scheduling 
(5)  output  data  requirements,  and  (6)  final  disposition  of  system  data. 

8.4.1  Required  input  data.  Input  data  requirements  may  vary  somewhat 
with  the  scope  of  a  particular  SCA,  differences  in  SCA  technique,  and 
peculiar  formatting  requirements  for  computer  processing.  Generally, 
the  data  package  will  include: 

a.  Schematics,  wiring  or  interconnection  diagrams,  cable  draw¬ 
ings,  wiring  harness  definitions,  etc. 

b.  Functional  descriptions  of  system  operation,  theory  of  opera¬ 
tion  documents,  and  perhaps  technical  briefing  by  design 
personnel . 

c.  Software  performance  specifications,  design  specifications, 
source  code,  preferably  on  magnetic  tape,  and  in  an  agreed 
format,  data  base  information,  and  operator's  manuals  if 
available. 

d.  Operational  procedures  documentation,  and  electromechanical, 
pneumatic  or  hydraulic  functional  diagrams  if  these  special 
features  are  to  be  involved  in  the  SCA. 

e.  Integrated  circuit,  hybrid  microcircuits,  and  special  com¬ 
ponent  schematics,  procurement  specifications,  and  description 
of  operation  documents. 

Data  requirements  should  be  agreed  upon  prior  to  award  of  contract.  The 
contract  should  specify  the  data  to  be  supplied  including  special 
formatting,  the  schedule  for  data  delivery,  and  a  cutoff  date  for  ECN 
inputs  after  which  schedule  and  cost  must  be  renegotiated. 

8.4.2  Securi ty.  The  contract  monitor  must  assure  that  the  performing 
activity's  facilities,  personnel,  and  computer  processing  facility  are 
cleared  to  handle  the  highest  classification  of  data  required  in  the  SCA 
effort. 


8.4.3  Output  data  requirements.  The  contract  must  include  CDRL  items 
for  all  required  deliverable  documentation,  including  progress  reports, 
final  reports,  worksheets,  and  magnetic  tapes  of  the  system  data  base. 
Each  CDRL  item  must  be  defined  by  a  DID.  If  the  performing  activity  is 
to  retain  the  data  base,  the  contract  must  specify  the  data  to  be  kept, 
and  the  duration.  If  the  data  are  to  be  returned,  the  contract  should 
specify  the  data,  schedule,  and  conditions  of  the  return. 

8.4.4  Special  data  considerations.  When  proprietary  data  is  involved 
in  an  SCA,  it  may  be  necessary  to  obtain  a  signed  agreement  from  the 
performing  activity  not  to  release  such  data  to  a  third  party  and  to  use 
such  data  only  in  the  performance  of  the  SCA.  The  SCA  data  base  in¬ 
cluding  input  data,  computer  data  base,  output  reports,  worksheets, 
etc.  should  normally  be  retained  by  the  performing  activity  for  a 
specified  period  to  ensure  its  availability  should  the  need  arise  to 
perform  SCA  on  system  modifications.  Maintenance  by  the  performing 
activity  will  be  more  cost  effective  and  the  risk  of  loss  is  less.  If 
the  data  are  returned  to  the  Government  or  the  design  activity,  pro¬ 
vision  should  be  made  for  storing  the  data  through  the  operation  and 
support  phase  of  the  system  life  cycle. 

8.5  Statement  of  work  examples.  Appendix  C  presents  some  examples  of 
statements  of  work  that  could  be  applied,  with  appropriate  tailoring, 
when  ordering  the  SCA.  Also  presented  is  a  DID  that  generally  reflects 
the  type  of  data  to  be  ordered. 


32 


9.0  COST  FACTORS 


9.1  General  cost  considerations.  Estimating  the  cost  of  an  SCA 
program  can  be  complicated  because  of  a  number  of  factors.  There  is  a 
variation  in  SCA  techniques  among  contractors  which  can  lead  to  signi¬ 
ficant  differences  in  their  cost  estimates  for  the  analysis.  The 
process  of  tailoring,  i.e.,  of  partitioning  the  system  and  using  dif¬ 
ferent  techniques  and  different  levels  of  scrutiny  in  the  analysis  of 
certain  subsystems  may  also  cause  a  wide  variation  in  cost  estimates 
for  what  is  apparently  the  same  job.  Other  factors,  such  as  the  degree 
of  accessibility  to  the  SCA  data  base,  the  level  of  government  involve¬ 
ment,  amount  of  liaison  required,  frequency  of  reports  and  specific  CDRL 
requirements,  will  all  have  an  effect  on  the  price  quoted  for  the  SCA. 

9.1.1  Assumptions.  It  is  assumed  in  this  section  (and  in  the  related 
Appendix)  that  the  technical  monitor  can  make  a  valid  independent 
assessment  of  the  technical  differences  among  SCA  methods  proposed  by 
different  contractors.  The  technical  monitor  must  further  assure  that 
the  scope  of  the  SCA  under  consideration,  including  system  partitioning 
and  special  considerations,  such  as,  system-level  SCA  only,  detailed  SCA 
of  MSI  or  LSI  circuits,  etc.,  is  clearly  defined  in  the  request  for 
quotation  (RFQ),  and  that  the  quotes  received  reflect  the  contractors' 
understanding  of  these  specific  tailoring  requirements.  It  is  further 
assumed  that  the  technical  monitor  will  include  contract  provisions  for 
monitoring  SCA  performance  sufficient  to  assure  that  the  SCA  is  per¬ 
formed  with  the  same  techniques,  partitioning,  and  levels  of  scrutiny  as 
were  quoted.  Only  after  all  of  these  preconditions  have  been  met  can  the 
technical  monitor  be  sure  that  the  price  quotes  are  truly  comparable  or, 
at  least,  that  the  price  quote  really  do  support  a  trade-off  decision 
between  cost  and  SCA  effectiveness. 

9.1.2  Cost  effectiveness.  The  application  of  SCA  on  a  program  must 
always  be  done  with  a  serious  consideration  for  cost  effectiveness. 

There  are  obvious  situations  in  which  SCA  is  clearly  mandatory,  such  as 
a  manned  space  flight,  a  nuclear  power  plant  control  system,  or  a 
nuclear  missile  system.  In  such  cases  the  consequences  of  sneak  con¬ 
ditions  are  potentially  disastrous;  the  costs  of  a  serious  error  are 
virtually  incalculable.  The  decision  in  most  other  cases  is  not  so 
clear-cut.  The  technical  monitor  must  weigh  the  potential  benefits  of 
SCA  against  the  cost  and  decide  either  to  do  it  or  not.  The  material  in 
Section  5  provides  some  assistance  in  making  this  decision. 

9. 1.2.1  Tailoring  to  reduce  costs.  Tailoring  the  SCA  to  reduce  costs 
while  maintaining  the  essential  benefits  of  the  analysis  is  strongly 
encouraged.  A  top-level  program  office  assessment  of  the  areas  in  the 
design  most  likely  to  generate  sneak  conditions  can  do  a  great  deal  to 
improve  the  cost  effectiveness  of  SCA  on  a  given  system.  Thus,  the 
built-in  test  equipment  (BITE)  circuitry,  or  the  interconnection  to  a 


test  set,  or  the  control  and  indicator  subsystems  could  be  singled  out 
as  the  primary  focus  for  SCA.  Experience  has  shown  that  power  dis¬ 
tribution  circuits  are  especially  susceptible  to  sneak  conditions  and 
are  thus  potential  candidates  for  the  SCA.  Of  course,  this  top-level 
tailoring  of  the  effort  should  remain  flexible  until  SCA  contractor 
inputs  regarding  proper  tailoring  are  heard  and  considered. 

9.1.3  Relation  to  other  activities  and  analysis.  Another  considera¬ 
tion  in  assuring  that  an  SCA  remains  cost  effective  is  the  efficient  use 
of  the  system  data  base.  The  configuration  management  costs  for  main¬ 
taining  an  accurate  system  data  base  can  be  substantial  for  a  large 
system.  An  effort  should  be  made  to  have  the  SCA  performed  by  the  same 
activity  that  performs  other  analyses  if  this  is  possible,  or  at  least 
to  minimize  the  number  of  activities  at  which  the  data  base  must  be 
maintained.  The  benefits  of  having  an  SCA  performed  by  an  independent 
agency  may  outweigh  the  additional  data  base  costs,  but  this  factor 
should  at  least  be  considered.  Some  cost  benefits  can  be  derived  by 
combining  analyses,  such  as,  SCA  with  FMECA  or  SCA  with  stress  analysis, 
especially  if  computer-aided  analysis  is  anticipated  for  these  other 
analyses. 

9.1.4  Separate  funding  of  SCA  phases.  The  cost  of  SCA  on  a  large 
system  is  likely  to  be  high.  The  cost  of  preparing  accurate  and  de¬ 
tailed  cost  estimates  for  performing  SCA  can  likewise  be  high.  The  most 
desirable  partitioning  of  the  system  for  cost  effectiveness,  or  the 
relative  effectiveness  of  several  candidate  SCA  techniques,  may  not  be 
obvious  at  the  outset  of  a  program.  In  such  cases,  the  contract  monitor 
should  consider  separate  funding  of  the  SCA  phases  discussed  in  Section 
8.2.2. 

9.2  Estimating  SCA  Costs.  Appendix  A  presents  some  general  guide¬ 
lines  for  estimating  the  cost  of  an  SCA.  The  guidelines  were  formulated 
in  part  from  historical  data  on  the  NASA-developed  sneak  path  analysis 
technique  and  its  derivative  software  SCA  procedure.  It  must  be  under¬ 
stood  that  none  of  these  were  competitive  procurements.  Consequently, 
the  data  on  historical  SCA  cost  may  be  a  poor  indicator  of  what  future 
cost  will  be.  One  of  the  primary  intentions  of  this  handbook  is  to 
encourage  the  development  of  innovative  and  cost  effective  SCA  pro¬ 
cedures.  The  combined  impact  of  price  competition,  innovation,  and  an 
effective  means  of  tailoring  SCA  to  fit  the  needs  of  particular  systems 
should  act  to  reduce  SCA  costs  in  the  future.  Appendix  A  also  suggests 

a  way  to  estimate  SCA  costs  independent  of  historical  data  so  that 
future  SCA  costs  may  be  at  least  roughly  estimated. 

9.3  Evaluating  costs.  The  best  means  of  evaluating  supplier  quotes 
is  to  form  an  independent  estimate  of  the  expected  cost  for  comparison. 
This  independent  estimate  must  be  based  on  what  the  supplier  proposes 
to  do  during  the  SCA,  i.e.  the  proposed  technique,  and  on  independent 
estimates  of  the  required  skill  levels,  manhours,  computer  time,  and 
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materials,  and  on  local  labor  rates,  company  overhead,  G&A,  and  profit. 
Appendix  A  suggests  a  general  outline  for  doing  this,  but  the  accuracy 
of  any  such  estimate  will  be  strongly  dependent  on  the  technical 
monitor's  knowledge  of  the  proposed  SCA  procedures,  and  his  persistence 
in  getting  accurate  data  for  the  estimate. 

9.3.1  Caveat.  The  very  existence  of  cost  guidelines  in  a  handbook 
such  as  this  will  undoubtedly  tend  to  precondition  or  "ballpark"  some 
supplier's  quotes.  The  technical  and  contract  monitors  should  be 
watchful  of  this  and  use  whatever  means  available  to  crosscheck  supplier 
quotes . 


APPENDIX  A 


ESTIMATING  SCA  COSTS 


10.1  Scope.  This  appendix  presents  information  to  assist  in  devel¬ 
oping  rough  order  of  magnitude  cost  estimates  for  the  performance  of 
Sneak  Circuit  Analysis  (SCA). 

10.2  Cost  estimating  procedures.  The  variation  in  SCA  procedures 
among  performing  activities  make  the  estimation  of  SCA  costs  quite 
tenuous  (see  Section  This  Appendix  is  presented  in  two  sections.  The 
first  section  presents  a  cost  estimation  process  which  is  based  on 
historical  cost  data  for  SCAs  using  the  sneak  path  search  technique 
developed  for  NASA  and  proprietary  derivative  techniques.  The  infor¬ 
mation  could  be  used  to  budget  for  SCAs  using  these  techniques.  It 
should  only  be  used  as  a  reference  point,  however,  on  SCAs  using  other 
methods.  The  second  section  provides  some  general  information  for  a 
government  technical  or  cost  monitor  in  budgeting  for  or  evaluating 
quotes  for  SCAs  using  other  procedures.  Because  of  the  potentially  wide 
variation  in  techniques,  this  information  can  only  be  very  general  to 
help  keep  the  monitors  from  overlooking  major  cost  elements  while 
working  up  an  independent  estimate  of  SCA  cost. 

10.2.1  Historical  SCA  costs.  Cost  data  have  been  provided  for  SCA  of 
both  hardware  and  software.  These  data  represent  the  historical  costs 
for  SCA  using  the  NASA-developed  path  search  technique  and  certain 
additional  proprietary  enhancements.  These  data  are  reasonably  regular 
and  support  a  linear  cost  relationship  with  parts  count,  except  near 
the  origin.  Because  of  the  differences  in  the  amount  of  labor,  computer 
time,  materials,  etc.,  required  to  analyze  different  part  types,  each 
part  type  has  a  different  weighting  factor  in  determining  the  cost  of 
the  SCA.  The  cost  (in  1979  dollars)  can  be  calculated  by  adding  to¬ 
gether  the  costs  for  each  individual  part  type.  Table  A-l  presents  the 
weighting  factors  for  different  part  types  and  their  approximate  tol¬ 
erances.  Table  A- 2  presents  a  sample  calculation  for  a  system  con¬ 
sisting  of  1000  parts  of  the  indicated  mix  ratio. 

10.2.1.1  Software  SCA  estimates.  The  cost  of  a  software  SCA  based  on 
historical  data  is  approximately  $10  per  assembly  code  instruction. 

10.2.1.2  Cost  estimating  accuracy.  Historically  the  accuracy  of  the 
parts-count  technique  presented  in  Table  A- 2  is  +102.  When  the  exact 
component  mix  is  not  known  and  the  weighting  factor  for  a  generalized 
component  mix  in  Table  A-l  is  used,  the  accuracy  is  +207.  Both  of  these 
estimators  produce  larger  errors  for  parts-counts  below  about  300  parts. 
In  this  region,  the  data  are  better  represented  by  a  constant  dollar 
figure  of  $30,000  +$20,000.  The  accuracy  for  estimating  software  SCA 
costs  using  the  cost  factor  of  10.2.1.1  is  +102. 
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Table  A-l.  Cost  Factors  for  Different  Part  Types. 


Part  Type 

Weighting 

Factor 

Weighting 

Factor 

Tolerance 

$/Part 

$/Part 

Resistors,  Capacitors, 

Coils 

29 

+8 

Relays,  Transistors, 

Swi tches 

79 

+11 

Small-Scale  Integrated 

Circuits  (SSI) 

164 

+  14 

Medium-Scale  Integrated 

Circuits  (MSI) 

284 

+  14 

Large-Scale  Integrated 

Circuits  (LSI) 

468 

i 

_25 

Generalized  Component  Mix 
(Used  when  actual  component 
mix  is  not  known) 

94 

+  19 

Table  A-2. 

Sample  Calculations. 

Part  Type 

Number 

of 

Parts  X 

Weighting 

Factor 

=  Component 
Cost 

Resistors,  Capacitors, 

Coi  1  s 

400  X 

29/Part 

=  $  11,600 

Relays,  Transistors, 

Switches 

200  X 

79/Part 

=  15,800 

SSI 

15.  X 

164/Part 

=  24,600 

MSI 

100  X 

284/Part 

=  28,400 

LSI 

50  X 

468/Part 

=  23,400 

Totals 

1 ,000 

$103,800 
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10.2.1.3  Cost  adjustments.  Costs  calculated  using  the  methods  of 

10.2.1  are  stated  in  1979  dollars  for  work  generally  performed  in  the 
Houston,  Texas,  area.  Cost  adjustments  for  inflation  in  later  years  and 
for  different  geographical  areas  can  be  made  using  current  statistics 
provided  by  the  U.S.  Department  of  Labor,  Bureau  of  Labor  Statistic 
s(BLS).  Examples  of  the  type  of  data  available  in  these  publications 
are  shown  in  Figure  A-l.  These  data  are  not  necessarily  current;  the 
latest  available  issues  of  the  BLS  data  should  be  consulted. 

10.2.2  Cost  estimates  for  other  SCA  procedures.  Estimating  the  cost 
of  an  SCA  when  new  or  innovative  procedures  are  to  be  performed  or  when 
the  scope  of  the  SCA  has  been  limited  by  some  tailoring  process  is  more 
difficult.  If  the  technical  monitor  is  sufficiently  knowledgeable  of 
the  SCA  procedure  which  is  to  be  used,  he  can  construct  an  estimate 
which  will  at  least  be  "in  the  right  ballpark."  An  SCA  cost  estimate  is 
developed  by  isolating  each  task  to  be  performed.  Preparing  a  Work 
Breakdown  Structure  (WBS)  of  the  required  tasks  is  a  very  useful  first 
step.  The  WBS  elements  involved  are  Project  Management,  Data  Management, 
Engineering  Analysis,  Quality  Assurance,  and  Reporting.  The  technical/ 
contract  monitor  would  estimate  the  engineering  and  support  time 
involved  in  each  WBS  element,  any  computer  charges  involved,  special 
materials,  equipment  charges,  and  travel.  It  is  not  the  intent  herein 
to  provide  a  "cookbook"  for  this  estimating  process,  but  rather  to 
identify  some  of  the  factors  that  should  be  considered. 

10.2.2.1  Engineering  skill  levels  required.  The  performance  of  SCA 
requires  an  analyst  possessing  certain  learned  SCA  skills  if  it  is  to  be 
performed  efficiently.  It  also  requires  a  depth  of  experience  in 
electrical  equipment  design  (or  in  software  coding  practices)  which  is 
not  generally  available  in  entry-level  personnel.  Most  detailed  elec¬ 
trical  SCA  will  be  done  by  engineers  in  categories  II,  III,  and  IV  as 
defined  by  the  U.S.  Department  of  Labor,  Bureau  of  Labor  Statistics. 

The  exact  mix  will  be  dependent  both  on  SCA  job  requirements  and  on  the 
engineering  mix  that  the  contractor  has  available  at  a  given  time.  The 
contractor  may,  for  example,  substitute  a  higher  engineering  category 
for  a  lower  one  if  there  is  an  insufficient  number  of  personnel  in  the 
lower  category  on  his  staff.  Equivalent  statements  can  be  made  for 
software  SCA  analysts;  personnel  capable  of  doing  software  SCA  normally 
have  titles  such  as  "Systems  Analysts"  or  "Sr.  Systems  Analysts".  The 
Department  of  Labor  Statistics  has  not  defined  skill  categories  in  this 
technical  discipline. 

10.2.2.2  ^Engineering  time  for  an  SCA.  Although  SCA  techniques  vary, 
they  have  certain  common  features: 

a.  Data  assimilation  and  entry.  This  is  normally  done  by  engi¬ 
neering  aides,  keypunch  operators,  or  computer  assistants.  It 
will  also  require  some  engineering  time  to  organize  and 
supervise  the  effort.  A  time  estimate  can  generally  be  made 
by  estimating  the  number  of  data  entries  involved  including 
any  verification  time. 


Table  1.  Average  Salaries:  United  States. 

Monthly  Salaries  Annual  Salaries 


b.  Computer  or  manual  data  processing  to  produce  usable  working 
materials  for  the  analyst,  such  as,  manageable  reduced 
network  schematics,  network  "trees",  assembly  code  flow 
diagrams,  etc.  This  is  likely  to  vary  so  much  with  different 
SCA  techniques  that  no  useful  guidance  can  be  given. 

c.  Detailed  analysis  by  a  trained  SCA  analyst  who  applies  certain 
"clues"  to  isolate  potential  sneak  circuits.  This  is  generally 
done  on  a  worksheet  of  some  sort  to  aid  in  the  "housekeeping" 
necessary  to  assure  completeness.  It  may  be  done  with  the 
asssistance  of  computerized  aids.  The  time  required  can 
normally  be  estimated  from  the  expected  number  of  hours  per 
worksheet.  It  should  be  remembered  that  this  is  the  step  in 
the  SCA  process  most  affected  by  tailoring.  Tailoring  will 
result  in  the  analyst  reviewing  fewer  networks,  worksheets, 
etc.,  thus  reducing  the  amout  of  analysis  time  required.  It 
would  be  expected  that  tailoring  would  result  in  a  significant 
deviation  from  the  linear  parts-count  relationship  presented 

in  10.2.1. 

d.  Report  preparation  costs  should  include  technical,  typing, 
editing,  and  drafting  labor,  and  any  special  equipment  and 
materials  cost  required  to  meet  specific  CDRL  requirements. 

10.2.2.3.  Taking  advantage  of  available  data.  The  process  of  cross¬ 
checking  a  supplier's  estimate  can  become  quite  involved.  The  Government 
monitors  should  take  advantage  of  all  available  data  sources  to  make 
their  estimates  as  accurate  as  possible.  Depending  on  the  situation, 
the  technical  or  contract  monitor  may  have  available  the  supplier's 
labor  rates,  overhead,  G&A,  and  fee  structure.  This  information  would 
be  available,  for  instance,  if  they  were  evaluating  a  supplier’s  quote 
on  any  cost-reimbursable  type  contract.  On  fixed  fee  or  incentive  fee 
type  contracts,  they  would  also  have  the  supplier's  estimate  of  total 
manhours  in  each  labor  category,  computer,  and  other  direct  costs  (ODC). 
If  the  SCA  effort  were  to  be  funded  in  phases,  they  would  also  have  the 
supplier's  estimates  by  phase.  Lacking  this  specific  information  on 
supplier  costs,  the  monitors  can  use  average  labor  rates  in  the  geo¬ 
graphical  area  involved  which  are  available  from  the  Department  of  Labor 
Statistics.  Approximate  rates  for  overhead,  G&A,  and  fee  structures  can 
be  found  in  other  contracts  with  the  involved  company  or  inferred  from 
similar  information  from  competitive  companies. 

10.2.2.4  Costs  of  subcontracting  SCA.  In  addition  to  the  costs 
involved  in  duplicating  the  SCA  data  base  at  a  subcontractor's  facility, 
standard  industry  practice  is  for  the  prime  contractor  to  add  G&A  and 
profit  charges  on  a  subcontracted  SCA.  Subcontractor  costs  will  already 
include  the  subcontractor's  G&A  and  fee  charges.  This  duplication  in 
charges  will  increase  costs  and  may  dictate  a  direct  contract  between 
the  government  and  the  performing  activity  in  some  instances,  but  this 
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consideration  must  be  traded  off  against  other  factors,  such  as  which 
activity  is  best  positioned  to  manage  and  understand  the  technical 
aspects,  and  costs  involved  in  incorporating  design  changes  as  a  result 
of  the  analysis. 

10.2.2.5  Including  government  costs.  In  addition  to  contractor  costs 
for  SCA,  the  costs  for  government  coordination  must  also  be  included. 
These  costs  would  include  any  special  costs  for  travel,  coordination, 
review,  or  independent  technical  consultant  services  associated  with  the 
SCA  effort. 
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APPENDIX  B 


ANALYSIS  TECHNIQUES 


20.0  Mechanics  of  performance.  The  general  procedures  followed  in 
performing  SCA  are  outlined  herein.  Exact  procedures  cannot  be  defined 
at  this  time  and  no  such  definition  is  intended.  Procedures  are  dis¬ 
cussed  generally  so  as  to  provide  a  knowledge  of  SCA  fundamentals  to 
help  the  technical  monitor  in  establishing  SCA  requirements,  reviewing 
proposed  new  SCA  techniques  and  reviewing  SCA  work  in  progress  at  a 
supplier's  facility.  Since  system  partitioning  is  an  essential  feature 
of  establishing  the  scope  of  an  SCA  this  subject  is  discussed  in  more 
detai 1 . 

20.1  General  procedures.  Although  SCA  techniques  may  vary  in  detail, 
all  of  the  established  techniques  have  been  based  on  the  methods  origi¬ 
nally  developed  for  the  National  Aeronautics  and  Space  Administration 
(NASA)  and  successfully  applied  in  the  space  programs.  As  electronic 
systems  technology  has  evolved,  some  of  these  procedures  have  been  found 
inadequate  to  analyze  new  systems,  notably  complex  digital  systems,  and 
integrated  hardware/software  systems.  New  techniques  have  been  developed 
to  cope  with  these  systems,  but  the  developers  have  considered  these 
(and  all  SCA)  techniques  proprietary,  hence  the  difficulty  in  defining 
exact  procedures.  The  general  procedure  followed  in  an  SCA  will  consist 
of  four  fundamental  steps,  (a)  assimilating  the  data,  (b)  organizing 
the  data  for  analysis  (generally  using  computer  data  processing), 

(c)  review  of  the  data  by  trained  analysts,  and  (d)  reporting  of  the 
results.  Obviously  this  scenario  fits  SCA  as  well  as  many  other  pro¬ 
cedures  used  to  analyze  systems,  so  some  further  definition  of  the 
process  is  required. 

20.1.1  Assimilating  the  data.  In  SCA  this  will  involve  two  kinds  of 
assimilation  of  data.  The  first  is  the  development  of  a  thorough 
understanding  of  the  system  and  how  it  works  by  the  persons  who  will 
analyze  it.  This  level  of  understanding  progresses  as  the  SCA  program 
develops.  The  understanding  of  details  of  system  operation  may  not  be 
necessary  to  make  a  reasonably  accurate  estimate  of  cost  and  schedule 
but  it  is  essential  to  the  persons  performing  the  detailed  analysis.  To 
clarify  this  somewhat,  it  should  be  stated  that  one  of  the  principal 
advantages  of  SCA  is  to  "highlight"  sneak  conditions,  thus  removing  the 
dependence  on  the  abilities  of  individual  analysts  to  an  extent. 
Nevertheless,  an  analyst  must  understand  the  operation  of  the  system  in 
detail  in  order  to  isolate  real  or  likely  sneak  conditions  from  the  many 
cases  which  are  "highlighted"  by  the  general  SCA  procedures.  The  second 
kind  of  data  assimilation  involved  in  SCA  is  the  formatting,  entry,  and 
verification  of  all  necessary  system  data  for  computer  (or  manual)  data 
processing.  Here  again,  SCA  may  differ  from  other  procedures  because 
the  intent  of  SCA  is  to  detect  sneak  conditions  in  the  system  as  built. 
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not  as  the  system  designers  might  think  it  is  built.  Consequently ,  the 
input  data  for  an  SCA  should  always  be  derived  from  the  best  available 
source,  the  production  definition  if  possible,  although  to  be  performed 
on  a  timely  basis,  it  will  almost  always  be  performed  on  some  earlier 
definition  and  later  updated  with  production  data. 

20.1.2  Organizing  the  data.  Data  processing  procedures  will  vary 
both  in  the  compatibility  of  data  formats  with  a  supplier's  data  base, 
and  with  the  degree  of  cross-verification  of  input  data  provided  by  the 
data  processing  programs.  The  intent  of  the  data  processing  programs  is 
to  verify  the  input  data  to  remove  errors  and  to  generate  the  working 
materials,  such  as  partial  schematics,  flowcharts,  etc.,  that  will  be 
used  in  the  next  step  in  the  analysis.  The  data  processing  programs  may 
also  automate  some  (but  never  all)  of  the  sneak  search  procedures  to  be 
used  by  the  sneak  circuit  analysts,  providing  certain  preprocessed  data 
to  be  used  in  the  next  phase  of  the  analysis.  The  data  processing  may 
also  be  performed  entirely  with  manual  rather  than  computer  data  pro¬ 
cessing  programs.  This  is  probably  best  limited  to  small  systems,  no 
larger  than  perhaps  100  to  200  total  parts  count  for  switching  and 
analog  systems,  50  small-signal  integrated  circuit  (SSI)  digital  sys¬ 
tems,  or  300-500  statement  software  programs. 

20.1.3  Detailed  sneak  circuit  analysis 

20.1.3.1  Sneak  path  analysis.  The  procedures  developed  for  NASA  were 
based  on  the  observation  that  certain  similarities  existed  among  sneak 
circuit  conditions  which  had  occurred  in  hardware  systems.  It  was  also 
observed  that  any  (electrical)  network  could  be  reduced  to  one  of  five 
subnetworks  called  "network  trees",  and  that  each  "tree"  could  be 
efficiently  analyzed  for  sneak  circuit  conditions,  using  the  accumu¬ 
lated  knowledge  gained  from  previous  sneak  circuit  situations.  A 
"network  tree"  is  a  portion  of  a  network  having  common  ties  with  other 
trees  only  at  power  or  ground  connections.  The  five  basic  types  of 
trees  are  shown  below: 


POWER(P) 

T 


\ 

GROUND  (G) 

SINGLE 

LINE 
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Although  some  networks  may  appear  more  complex,  they  can  always  be  re¬ 
presented  as  a  combination  of  these  five  basic  trees.  The  impedance 
elements  in  the  trees  may  be  combination  of  electrical  impedances, 
wires,  connector  pins,  switch  contacts,  etc.  In  the  NASA  procedure, 
detailed  lists  of  "clues"  were  developed  to  analyze  each  type  of  network 
tree.  The  clues  are  based  on  both  theoretical  principles  and  on  ex¬ 
perience  with  other  sneak  conditions  which  have  occurred  historically. 
The  clues  for  a  particular  type  of  network  tree  are  used  whenever  that 
type  tree  is  encountered  in  an  SCA.  The  clue  lists  and  computer  data 
processing  programs  are  the  primary  features  of  SCA  considered  pro¬ 
prietary  by  most  companies.  Because  of  this,  a  comprehensive  list  of 
SCA  clues  cannot  be  presented  here.  However,  to  indicate  what  kind  of 
clues  are  involved  several  typical  ones  are  presented.  One  clue  which 
is  nearly  always  applied  is  to  consider  the  timing  and  direction  of 
currents  in  the  tree.  The  conditions  of  switches  in  the  tree  are  anal¬ 
yzed  to  see  if  all  switch  conditions  lead  to  intended  currents  in  the 
network.  The  existence  of  currents  in  a  reverse  direction  from  the 
normally  intended  current  is  also  a  clue  that  a  sneak  circuit  may  be 
present.  The  generation  of  network  trees  is  normally  done  with  computer 
assistance.  Further  reduction  of  network  trees  down  to  essential 
elements  is  normally  performed  using  either  manual  or  computer-assisted 
methods.  Essential  elements  are  those  which  might  possibly  lead  to  a 
sneak  condition,  and  will  include  control  elements  such  as  relay  coils, 
transistors,  switches,  pull-out  connector  pins,  etc.  Certain  non- 
essential  elements  may  be  eliminated,  e.g.  fixed  impedances,  hardwired 
connections,  pins  of  connectors  that  are  not  removed  during  operation, 
etc.,  in  order  to  simplify  later  analysis.  This  step  becomes  the  con¬ 
trolling  consideration  in  deciding  whether  computer  data  processing  is 
required  to  perform  sneak  path  analysis.  Because  of  the  difficulty  in 
visualizing  network  trees  (or  some  equivalent  subnetwork  in  a  different 
SCA  process),  manual  sneak  path  analysis  should  only  be  done  on  systems 
below  about  100-200  component  parts.  Once  the  system  circuitry  has  been 
reduced  for  analysis,  sneak  circuit  clues  are  applied  by  the  analysts  to 
each  reduced  network.  This  process  is  normally  the  most  time  consuming 
in  the  SCA.  The  analysts  may  be  assisted  in  this  process  by  numerous 
computer  data  processing  outputs  which  tend  to  reduce  the  amount  of  time 
required  to  apply  clues. 

20.1.3.2.  Digital  SCA  procedures.  The  process  just  described  has 
been  defined  as  "sneak  path  analysis".  The  derived  technique  of  digital 
sneak  circuit  analysis  arose  primarily  because  of  the  difficulty  in 
analyzing  the  multiplicity  of  possible  states  of  a  digital  system  by 
considering  each  state  independently  in  a  manual  (really  a  thought 
process)  analysis.  Consequently,  some  digital  SCA  procedures  have  been 
modified  to  take  advantage  of  available  logic  analyzer  or  logic  simu¬ 
lator  computer  programs  in  addition  to  the  more  conventional  sneak  path 
analysis  procedures.  Digital  logic  systems  are  more  easily  analyzed  by 
tracing  functional  signal  paths  through  the  network  rather  than  power- 
to-ground  network  trees.  This  type  of  analysis  can  be  done  manually  up 
to  about  50-75  SSI  circuits  or  about  20-25  MSI  circuits.  Beyond  this, 
computer-assisted  techniques  should  be  used. 
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20.1.3.3  Software  SCA  procedures.  Software  SCA  was  derived  from  the 
application  of  the  principles  of  sneak  path  analysis  for  hardware  to 
computer  program  flow  diagrams.  Here  again,  clues  are  applied  that  are 
specific  to  particular  flow  diagram  topographs.  The  procedure  may 
utilize  computer  aids  to  analyze  the  multiplicity  of  input  conditions 
for  a  given  flow  diagram,  and  it  may  involve  an  adaptation  of  hardware 
path  search  software  to  generate  the  suspect  flow  diagram  topographs. 

It  is  also  quite  likely  that  new  software  code  analyzer  programs  will  be 
developed  with  many  of  the  same  features  as  software  SCA  and  will  be 
used  as  substitute  analytical  procedures.  Software  SCA  can  also  be 
performed  manually  on  small  programs.  The  limits  is  probably  in  the 
range  of  300-500  code  statements  for  relatively  well  structured  code. 

If  the  code  is  poorly  structured,  the  limit  could  be  much  lower.  There 
are  also  derived  SCA  techniques  for  handling  both  hardware  elements  and 
software  code  statements  in  the  same  topographs,  i.e.,  hardware/software 
integration  analysis.  This  is  a  relatively  new  procedure  and  little 
guidance  beyond  that  provided  herein  for  evaluating  new  SCA  methodo¬ 
logies  can  be  given. 

20.1.3.4  Supplementary  considerations.  All  of  the  defined  types  of 
SCA  involve  the  application  of  certain  formalized  clues  to  isolate  sneak 
circuit  conditions.  Since  the  entire  system  will  be  scruntinized  by  a 
group  of  trained  analysts,  the  SCA  offers  an  excellent  opportunity  to 
review  other  features  of  the  design  which  might  cause  it  to  malfunction, 
although  they  are  not  considered  as  sneak  conditions,  per  se.  Con¬ 
sequently,  the  clue  lists  used  in  SCA  have  generally  been  expanded  to 
include  additional  features  which  the  analysts  look  for  in  addition  to 
sneak  conditions.  Thus,  overstressed  parts,  single  point  failures, 
excessive  fan-out,  documentation  errors,  and  unused  circuitry  may  also 
be  identified  during  an  SCA.  The  SCA  is  not  comprehensive  in  these 
areas,  but  can  be  very  useful  as  a  "second  check".  The  SCA  contract 
should  be  explicit  in  specifying  which  of  these  supplementary  features 
are  to  be  considered ■ in  the  SCA;  otherwise  they  may  be  omitted  from 

the  analysis  by  the  performing  activity  to  reduce  costs. 

20.1.4  Reporting  SCA  results.  SCA  results  are  reported  in  the  con¬ 
ventional  manner,  although  supplier's  formats  may  vary.  Section  8.4 
provides  guidance  on  specifying  reporting  requirements. 

20.2  System  partitioning.  An  SCA  can  be  performed  at  any  one  of 
several  levels,  depending  on  a  variety  of  factors  which  have  been  con¬ 
sidered  in  this  handbook.  Within  certain  constraints,  the  levels  of  SCA 
may  be  mixed  to  provide  increased  scruntiny  on  selected  portions  of  the 
system.  There  are  two  primary  reasons  for  partitioning  a  system.  The 
first  is  to  assist  in  defining  the  scope  of  the  SCA.  The  SCA  may  be 
performed  at  system  level,  subsystem  level,  or  device  level.  Certain 
more  or  less  independent  functions  can  also  be  isolated  for  intensive 
analysis,  e.g.  the  Built-in-Test  (BIT)  features,  the  power  distribution 
or  ground  distribution  networks,  or  the  specific  circuits  involved  in 
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the  arming  and  firing  of  explosives.  The  trade-offs  involved  in  deter¬ 
mining  the  most  cost  effective  scope  for  an  SCA  are  discussed  in  Sec¬ 
tion  9.  The  second  reason  for  partitioning  is  to  isolate  certain  portions 
of  the  system  to  simplify  subsequent  analysis.  For  example,  an  obvious 
partitioning  might  be  to  break  a  system  at  a  hardware/software  inter¬ 
face,  or  between  power  distribution  circuits  and  digital  subsystems. 

This  type  of  partitioning  would  be  used  to  adapt  the  system  to  a  sup¬ 
plier's  specific  SCA  procedures. 

20.2.1  System  level  SCA.  A  system  level  SCA  concentrates  on  the 
system  interconnections  between  subassemblies,  considering  subassembly 
inputs  and  output  as  loads  or  sources  respectively,  and  considering 
subsystem  functions  as  correctly  generated,  without  considering  possible 
sneak  conditions  within  subsystems  or  at  any  lower  level.  Power  dis¬ 
tribution  and  ground  distribution  circuits  would  also  be  included. 

Signal  flow  would  be  considered;  however  signal  generation  would  not. 

All  system  level  switching  functions  and  all  system  level  discrete 
components  would  normally  be  included.  System  level  SCA  is  most  appro¬ 
priate  where  subassemblies  are  well  understood,  either  because  they  are 
standard  assemblies  in  wide  usage  or  there  is  some  other  background  of 
good  historical  data  on  the  subassemblies.  It  must  be  pointed  out  that 
any  tailoring  process  reduces  the  effectiveness  of  SCA  to  an  extent,  and 
performing  system  level  SCA  alone  may  permit  some  sneak  conditions  at 
subsystem  level  or  below  to  slip  through.  Abiding  by  these  suggested 
constraints  should  minimize  the  "leakage"  for  the  dollars  spent. 

20.2.2  Subsystem  level  SCA  A  subsystem  (or  "black-box")  level  SCA 
provides  an  additional  level  of  discrimination  beyond  that  of  system 
level  SCA.  In  the  subsystem  level  SCA,  each  of  the  subassemblies  is 
also  considered  for  possible  generation  of  sneak  conditions.  Subsystems 
would  normally  be  represented  by  the  discrete  components  making  up  the 
subsystem,  except  that  integrated  devices  would  be  represented  by  their 
logical  functions  or  by  their  analog  function  e.g.  by  an  operational 
amplifier  rather  than  by  the  integrated  components  making  up  the 
operational  amplifier.  Performance  of  subsystem  level  SCA  normally 
presupposes  the  performance  of  system  level  SCA  although  exceptions  are 
possible.  Subsystem  level  SCA  provides  additional  assurance  that  most 
sneak  conditions  will  be  found,  normally  at  a  relatively  large  increase 
in  cost.  It  is  appropriate  for  newly-designed  subsystems  or  subsystems 
which  have  no  background  of  trouble-free  historical  data,  which  might 
justify  their  exclusion  from  the  SCA.  Subsystem  SCA  can  be  performed  on 
all  subsystems  or  on  selected  subsystems,  e.g.  BIT  circuitry  within  a 
system  level  SCA. 

20.2.3  Device  level  SCA.  The  device  level  SCA  considers  all  parts  in 
a  given  subsystem,  even  integrated  circuits  at  their  fundamental  com¬ 
ponent  level,  e.g.  a  digital  logic  integrated  circuit  would  be  rep¬ 
resented  as  an  assemblage  of  resistors,  capacitors,  transistors,  diodes, 
etc.  The  device  level  SCA  might  be  used  to  analyze  a  particular  integrated 
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circuit  or  selected  integrated  circuits  within  a  subsystem  level  SCA. 

It  might  also  be  used  totally  independently  to  analyze  a  new  integrated 
circuit.  Device  level  SCA  can  be  expected  to  be  relatively  more  ex¬ 
pensive  than  "subsystem  level  SCA."  It  would  normally  not  be  cost 
effective  to  do  device  level  SCA  on  a  complete  system  consisting  of  many 
integrated  circuits. 
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APPENDIX  C 
STATEMENT  OF  WORK 


30.1  General .  This  appendix  presents  some  examples  of  contract 
statements  of  work  that  may  be  applicable  when  ordering  an  SCA,  and  a 
typical  Data  Item  Description  (DID).  Statements  of  work.  Contract  Data 
Requirements  Lists  (CDRL),  and  DIDs  must  be  appropriately  tailored  for 
each  individual  situation. 

30.2  Examples .  Examples  of  general  statements  of  work  and  options 
which  may  be  selected,  depending  on  the  individual  circumstances,  are 
presented  in  exhibits  C-l  through  C-12. 

30.3  Data  item  description  (DID).  Representative  DIDs  describing 
typically  required  data  items  to  be  delivered  in  conjunction  with  the 
SCA  are  included  at  the  end  of  this  appendix. 


Perform  a  (software)  sneak  circuit  analysis  of  the  _  system. 

The  analysis  shall  be  performed  using  established  contractor-developed 
procedures  and  shall  identify  latent  electrical  paths  (or  software 
logic  control  paths)  which  can  cause  an  undesired  function  to  occur  or 
can  inhibit  a  desired  function.  Analysis  results  shall  be  reported  in 
accordance  with  item  A001  of  the  attached  Contract  Data  Requirements 
List  (CDRL).  Periodic  status  reports  shall  be  submitted  during  the 
course  of  the  analysis  in  accordance  with  item  A002  of  the  attached 
CDRL. _ _ 

Exhibit  C-l.  General  Statement  of  Work 


The  sneak  circuit  analysis  shall  be  limited  to  the  system  level.  As 
such  it  shall  include  the  interconnections  of  all  subassemblies 
defined  in  the  attached  drawing  list,  all  power  distribution  and 
control  circuits,  all  ground  circuits,  all  relay  and  panel  switching, 
and  all  system  level  discrete  components. _ 

Exhibit  C-2.  System  Level  Option 


The  sneak  circuit  analysis  shall  be  limited  to  the  (name(s))  sub- 
system(s)  defined  in  the  attached  drawing  list  and  to  its  (their) 
interconnections  within  the  systems.  Within  the  subsystem,  the  SCA 
shall  be  taken  to  the  device  function  level  for  subsystem  components. 
All  power  distribution  and  control  circuits,  all  ground  circuits,  all 
relay  and  panel  switching  and  all  system-level  discrete  components 
involved  in  the  interconnections  of  the  specified  subsystem(s)  into 
the _ system  shall  be  also  included  in  the  analysis. 

Exhibit  C-3.  Subsystem  Level  Option 
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Exhibit  C-6.  Software  SCA  Option 


In  addition  to  latent  paths,  the  SCA  shall  identify,  to  the  extent  of 
the  limitations  in  scope  defined  above,  all  instances  of  the  following 
conditions  noted  during  the  analysis: 

a.  Single  point  failures 

b.  Lack  of  relay  transient  protection 

c.  Drawing  and  documentation  errors 

d.  Unnecessary  or  unused  circuitry 

Exhibit  C-7.  Additional  Reporting  Options 


The  analysis  shall  be  performed  in  phases  as  defined  below.  Each 
phase  shall  be  funded  separately.  Prior  to  the  end  of  each  phase,  the 
Government  shall  release  funds  for  the  subsequent  phase  provided  that 
the  delivered  items  provided  to  that  point  are  acceptable.  In  the 
event  that  the  delivered  items  are  unacceptable  or  that  a  change  or 
limitation  in  scope  is  necessary,  the  contract  shall  be  renegotiated 
prior  to  initiation  of  the  next  phase. 

Exhibit  C-8.  General  Phasing  Statement 


Phase  1  During  the  initial  phase,  the  contractor  shall  define  the 
system  which  is  to  be  subjected  to  SCA,  including  the  drawings  issues, 
computer  program,  configuration  items,  and  level  of  analysis  to  be 
applied  in  each  area  of  the  system.  Methods  to  be  used  in  each  system 
area  shall  be  defined.  Results  and  recommendations  for  system  parti¬ 
tioning,  lists  showing  required  drawings,  data  items,  documents  and 
identifying  any  missing  documentation  shall  form  a  part  of  the  peri¬ 
odic  status  report  immediately  preceding  the  completion  of  Phase  1. 

Exhibit  C-9.  Phase  1  Option 


Phase  2  The  SCA  shall  be  performed  at  the  system-level  and  to  the 
subsystem  level  to  the  extent  defined  in  the  contract.  Preliminary 
results  and  recommendations  during  this  phase  shall  form  a  part  of 
periodic  status  reporting.  The  contractor  shall  make  recommendations 
during  this  phase  relative  to  any  subassemblies  or  integrated  circuits 
which  should  be  analyzed  at  the  device  level,  and  shall  include  this 
in  the  periodic  status  report  immediately  preceding  the  completion  of 
Phase  2.  Any  computer  program  configuration  items  requiring  detailed 
analysis  shall  also  be  identified  and  similarly  reported. _ 

Exhibit  C-10.  Phase  2  Option 


Phase  3  The  SCA  shall  be  completed  to  the  device- level  to  the  extent 
defined  in  the  contract.  The  contractor  shall  update  the  complete  SCA 
to  include  any  system  changes  made  to  correct  problems  identified 
during  previous  phases.  Summary  results  and  recommendations,  in¬ 
cluding  current  status  of  disposition  of  recommended  changes  shall  be 
included  in  the  final  report. _ _ _ 

Exhibit  C- 11.  Phase  3  Option 


Phase  4  The  contractor  shall  provide  monitoring  and  evaluation  of 
system  changes  and  shall  update  the  SCA  to  the  extent  required. 
Results,  recommendations,  and  current  status  of  all  problem  disposi¬ 
tions  shall  be  included  in  the  periodic  status  reports  during  this 
phase.  If  directed,  the  contractor  shall  update  the  final  report  to 
reflect  the  final  dispositions  of  all  identified  problems  at  the 
conclusion  of  Phase  4. _ 

Exhibit  C-12.  Phase  4  Option 
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DATA  ITEM  DESCRIPTION 


IDENTIFICATION  NOISI 


2 


l/a  im  i  i  cm  ucjorvir  i  ion 

AGENCY 

NUMBER 

1  TITLE 

Sneak  Circuit  Analysis  Plan 

NAVY-SE 

3.  DESCRIPTION/  PURPOSE 

This  plan  presents  the  contractor's  concept  of  the  sneak 
circuit  annalysis. 

4  APPROVAL  DATE 

5  OPFICE  OF  PRIMARY 

R  ESPON  SI  Bl  LIT  Y 

«  DDC  REQUIRED 

6  APPROVAL  LIMITATION 

7  APPLICATION/INTERRELATIONSHIP 

This  Data  Item  Description  is  applicable  to  any  phase  when 
complete  documentation  is  available. 

The  following  DID's  are  interrelated: 

DI-R-22594  Analysis,  Sneak  Circuit 

DI-R-XXXXX  Status  Report,  Sneak  Circuit  Analysis 

A  REFERENCES  (Mandatory  as  cited  in 
block  JO) 

MIL-STD-785A 

Notice  1  (EC) 

MCSL  NUMBER1SI 


10  PREPARATION  INSTRUCTIONS 

10.1  The  Sneak  Circuit  Analysis  Plan  shall  include,  but  is  not  limited  to,  the 
following : 

a.  Scope  of  analysis  including  hardware  and  software  to  be  analyzed 

b.  Data  required  to  perform  the  analysis 

c.  Reports  to  be  submitted 

d.  Methoiodgy  to  be  used 

e.  Schedule  for  performing  analysis 

f.  Corrective  action  procedure 

10.2  The  plan  shall  be  in  contractor's  format. 


DD 


FORM 

i  jon  es 


1664 


S/N*0102*0!9- 4000  PLATtNO. 


DATA  ITEM  DESCRIPTION 

2  IDENTIFICATION  NO'S,  | 

AGENCY 

NUMBER 

1  TITLE 

Sneak  Circuit  Analysis  Status  Report 

3.  DESCRIPTION/  PURPOSE 

This  report  presents  the  progress  that  has  been  made  to  date 
on  the  sneak  circuit  analysis. 

4  APPROV  AL  DATE 

5  OFFICE  OF  PRIMARY 

RESPONSIBILITY 

6  DOC  REQUIRED 

8  APPROVAL  LIMITATION 

7  APPLICATION  INTERREL  ationship 

The  following  DID's  are  interrelated: 

DI-R-22594  Analysis,  Sneak  Circuit 

DI-R-XXXXX  Plan,  Sneak  Circuit  Analysis 

9  REFERENCES  (Mandfl(of)-  as  cited  in 

block  10) 

MIL-STD-785A 

Notice  1  (EC) 

MCSL  NUMBERISI 

«r.  PREPARATION  INSTPUCTION5 


10.1  The  status  report  will  provide  an  accounting  of  work  accomplished  to  date  and 
planned  tasks  for  the  next  reporting  period. 

10.2  The  report  shall  be  in  contractor's  format. 


OP 


DD--1664 


S  'N  •  0  1  O  2  •  0  1  0  •  4000 


P  LATI  A40  .  19  448 


»’ASE 


P  ACES 
r  -  6  M  7 


DATA  ITEM  DESCRIPTION 


IDENTIFICATION  NOISI 


2  IDENTIFICATION  NOISl  | 

AGENCY 

NUMBER 

1  TITl_E 

REPORT,  SNEAK  CIRCUIT  ANALYSIS  (SCA) 

NAVY 

3  DESCRIPTION-  PURP(  SE 

3.1  Description.  The  SCA  report  describes  all  sneak  cir- 
cuit  conditions  identified  during  the  formal  SCA  and  provides 
recommendations  for  their  correction.  The  report  also  des¬ 
cribes  and  recommends  solutions  for  other  design  problems 
discovered  during  the  SCA.  In  addition,  provision  is  made 
for  retention  of  critical  SCA  data, 

3.2  Purpose.  The  SCA  report  is  used  to  document  the 
results  and  to  ensure  the  thoroughness  and  completeness  of 
the  sneak  circuit  analysis. 

4  APPROV  AL  DATE 

5  OFFICE  OR  PRIMARY 

R  ESPONSI  Bl  L  IT  Y 

6.  DDC  REQUIRED 

6  APPROVAL  LIMITATION 

7.  APPLIC  AT  ION  INTERREL  ATIONSHIP 

7.1  Application.  Sneak  circuit  analysis  is  applicable  to 
mission  critical  hardware  and  software  systems  and  equipment, 
The  SCA  is  applicable  to  system,  subsystem,  or  equipment 
levels , 

7.2  Interrelationship.  The  SCA  may  be  implemented  inde- 
pendently  or  as  one  of  the  specific  tasks  in  accordance  with 
a  reliability  program  in  accordance  with  MIL-STD-785.  SCA 
results  may  also  be  useful  in  performing  hazard  analysis  in 
accordance  with  MIL-STD-882. 

9  REFERENCES  (Mandatory  as  cited  in 
block  10) 

MIL-STD-785 

MIL-STD-882 

MCSL  NUMBER(S) 

10  PREPARATION  INSTRUCTIONS 


10.1  General .  Unless  otherwise  specified  by  the  contracts,  the  documents  cited  in 
this  block,  of  the  issue  in  effect  on  the  date  of  award  form  a  part  of  this  Data  Item 
Description  to  the  extent  specified  herein. 

10.2  Content .  The  SCA  report  shall  detail  the  results  of  the  SCA  performed,  and 
shall  include  the  following  items: 

a.  Discussion  of  the  SCA  methodology  used  and  any  assumptions  made  in  performing 
the  analysis. 

b.  Tabulation  of  all  actual  or  suspected  sneak  circuit  conditions  including: 

(1)  Identification  of  the  circuit,  computer  program,  situation  or 
condition  creating  the  sneak  circuit. 

(2)  Discussion  of  the  conditions  causing  or  suspected  of  causing  the 
sneak  circuit  condition. 

(3)  Recommendations  for  the  correction  of  all  sneak  circuit  conditions. 

c.  Reports  of  any  and  all  drawing  or  design  errors,  suspected  design  oversights, 
inconsistencies,  or  incompatibilities  noted  during  the  analysis.  Situations 
to  be  reported  shall  include  overstressed  or  overloaded  components,  single 
point  failures,  unused  or  inaccessible  circuitry  or  computer  code,  and  lack 
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DATA  ITEM  DESCRIPTION 


identification  NOISI 


2  IDENTIFICATION  NO<S)  ] 

PWTM  i  i  L m  i  i wn 

AGENCY 

NUMBER 

1  TITLE 

REPORT,  SNEAK  CIRCUIT  ANA1.YSIS  (SCA) 

NAVY’ 

3.  DESCRIPTION  PURPOSE 

4  APPROV  AL  DATE 

S  OFFICE  OF  PRIMARY 

R  ESPON  SI  B(L  »T  V 

«  DPC  REQUIRED 

4  APPROVAL  LIMITATION 

y  REFERENCES  (, Mandatory  as  cited  in 
block  10) 

MCSL  NUMBERISI 

to  PREPARATION  INSTRUCTIONS 


of  transient  suppression  devices,  to  the  extent  these  were  identified  in  the 
SCA. 

d.  A  complete  record  of  drawings  used  in  the  analysis,  including  drawing 
revision,  engineering  change  notices,  and  any  exceptions  taken  during 
the  SCA. 

e.  A  complete  record  of  the  computer  data  base  used  in  the  analysis,  including 
input,  intermediate,  and  output  data  adequate  to  duplicate  or  update  the 
SCA.  Upon  contractual  agreement,  this  data  base  may  be  retained  bv  the 
contractor  for  a  specified  period. 

f.  Analyst  worksheets  used  in  the  SCA  to  the  extent  specified  in  the  contract. 

10.3  Format  SCA  reports  may  be  supplied  in  contractor's  format. 
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